Czy EAI może być zwinne? Spis treści

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

Download "Czy EAI może być zwinne? Spis treści"

Transkrypt

1 Spis treści 1. Wprowadzenie Definicje Warunki brzegowe Koncepcje Service Strategy Service Design Service Transition Service Operation Continual Service Improvement Podsumowanie Bibliografia

2 1. Wprowadzenie Zwinne podejście do wytwarzania oprogramowania wkroczyło na poważnie do świata IT, o czym świadczy chociażby dedykowana metodyka Microsoftu MSF for Agile. W sformalizowanym obszarze integracji akceptacja dla zwinnych metodyk jest mniejsza, ale niewątpliwie dostrzegane są jej plusy takie jak skrócenie okresu time to market czy lepsze radzenie sobie w sytuacjach niedoskonałej analizy lub nagłych zmian w trakcie trwania projektu. 1.1 Definicje Aby zastanowić się nad możliwościami zastosowania zwinnych metodyk w obszarze Enterprise Architecture Integration spróbujmy najpierw wypracować jego definicję. EAI należy rozumieć jako zastosowanie oprogramowania typu middleware (platformy) do stworzenia architektury integrującej heterogeniczne systemy poprzez zapewnienie możliwości realizacji przepływów biznesowych z uwzględnieniem odpowiednich wzorców, dobrych praktych oraz ustandaryzowanych rozwiązań technologicznych. Mówiąc o EAI często pojawiają się inne terminy takie jak SOA (Service Oriented Architecture) oraz ESB (Enterprise Service Bus). Momentami pojęcia te są nieostre i zachodzące na siebie. Architektura zorientowana na usługi postuluje realizacje produktów biznesowych poprzez implementację za pomocą instrumentacji możliwie jak najbardziej atomowych i reużywalnych usług, będących bytami technologicznymi. W dojrzałej architekturze SOA usługa tworzona dla nowego produktu biznesowego jest usługą złożoną (kompozytową) korzystającą z już istniejących usług, a czas jej wykonania jest relatywnie krótki. Szyna usług korporacyjnych to ewolucyjne i marketingowe podejście do EAI. ESB zakłada istnienie natywnej inteligentnej warstwy transportowej, do której za pomocą wtyczek można podpiąć dowolny system. Usługi udostępnione w ramach ESB są niezależne od warstwy transportowej (mogą być używane poprzez WebService, JMS, itd.). Komunikaty przepływające wewnątrz ESB mogą być przekierowywane i modyfikowane według określonych reguł. Nowoczesna szyna zapewnia monitoring działania usług z mierzeniem i egzekwowaniem SLA, wirtualizację usług poprzez load balancing, failover, korzystanie z rejestru, mediację między protokołami transportowymi, często też posiada rozwiązanie BPM (Business Process Management) do realizacji długo trwających procesów 2

3 biznesowych, w których oprócz kroków automatycznych (wywołania wspomnianych wcześniej serwisów) pojawiają się aktywności realizowane ręcznie przez człowieka. Dzięki dobrze zaprojektowanej i wdrożonej architekturze SOA firma może być zwinna (pojawia się tu określenie Enterprise 2.0 nawiązujące do Web 2.0). Zwinność polega na łatwym reagowaniu na sytuację na rynku i łatwość w modyfikowaniu istniejących i wprowadzaniu nowych produktów. Trzeba mocno podkreślić, że SOA nie da się kupić, bo jest to wzorzec architektoniczno-projektowy byt abstrakcyjny. Samo kupienie platformy integracyjnej nie jest kupieniem SOA. SOA trzeba zaprojektować i zbudować od podstaw. Można mieć platformę integracyjną oraz źle zaprojektowane środowisko i w rezultacie nie mieć SOA. Pomocą w implementacji SOA może być EAI lub ESB. Rys. 1. Magiczna Ćwiartka Gartnera projekty EAI Back-End, 2008 Dwuwymiarowa (wizja, potencjał) klasyfikacja produktów. Należy zwrócić uwagę, że ESB też nie jest stricte produktem. To kolejny koncept/wzorzec architektoniczny/projektowy, który odróżnia się od EAI tym, że zakłada możliwość podłączenia do platformy integracyjnej za pomocą różnorodnych adapterów/klientów dowolnego systemu (komunikacja inbound platformy) i vice versa - platforma może podłączyć się do każdego systemu (komunikacja outbound), natomiast usługi 3

4 wewnątrz platformy (szyny) używają komunikacji natywnej (historycznie jest to JMS), która powinna być wydajna i zoptymalizowana. Usługi wewnątrz platformy integracyjnej zbudowanej na ESB są niezależne od transportu. ESB przydaje się w heterogenicznych środowiskach, w których naprawdę mamy wiele różnych systemów i technologii (Oracle, MSSQL, EJB, JMS, WS). ESB to nie SOA (ESB może być tylko sposobem na wdrożenie SOA). Do linii produktowych dostarczających funkcjonalność EAI/ESB należą: Apache ServiceMix IBM WebSphere Microsoft BizTalk Oracle Fusion Sun OpenESB Software AG webmethods Tibco ActiveMatrix Rys. 2. Magiczna Ćwiartka Gartnera projekty kompozytowe SOA,

5 Nie posiadając w/w oprogramowania EAI/ESB można stworzyć dużo większym nakładem pracy architektów, projektantów i programistów za pomocą framework-ów typu Spring czy Grails. ESB ustandaryzowała firma Sun Microsystems wprowadzając model JBI (Java Business Integration), który zaadaptowały platformy Apache ServiceMix, Oracle Fusion i Tibco. Warto zastanowić się, co jest istotą podejść zwinnych? Mikrozarządzanie 1. Rezygnuje się z ciężkiego zarządzania projektem na wysokim poziomie, a stosuje się je tam, gdzie naprawdę jest ono konieczne i potrzebne. Zarządzanie pojawia się przy kartach CRC i w momencie refactoringu w XP, wyciąganiu aktualnie wymaganej funkcjonalności w Kanbanie, analizie zadań bieżącej iteracji w Scrumie, wreszcie w momencie retrospekcji po zakończeniu zadania. 1 Artem Marchenko, 5

6 2. Warunki brzegowe Zdefiniujmy cele, jakie dla metodyki zwinnej w obszarze EAI należałoby postawić: iteracyjne podejście do projektów, wpisujące się w podejście ciągłej integracji w EAI (wdrożenie platformy integracyjnej jest procesem, który ciągle trwa i sam się udoskonala) skrócenie czasu trwania projektu liczonego od momentu analizy do momentu wdrożenia, a w rezultacie oszczędność środków finansowych uzyskanie przewagi nad konkurencją poprzez szybsze wprowadzanie nowych produktów biznesowych minimalizacja strat na projektach, które zostały przerwane możliwość wprowadzenia priorytetów dla produktów projektu i faktycznego ich egzekwowania zachowanie stabilności projektu po wprowadzeniu dużych zmian wymagań faktyczna reużywalność usług podniesienie jakości produktów zapobieganie degradacji architektury poprzez jej refactoring (extreme Programming zakłada refactoring kodu) Jakie zagrożenia są możliwe do przewidzenia? brak wiedzy na jakim etapie projektu się znajdujemy (w metodykach formalnych odseparowane od siebie były analiza, programowanie z wydzielonymi kamieniami milowymi, testowanie) i kiedy się on skończy problemy komunikacyjne pomiędzy analitykami biznesowymi/biznesowymi opiekunami projektu a programistami problemy w przestawieniu się biznesu i osób nadzorujących wytwarzanie 6

7 oprogramowania z podejść formalnych na zwinne (platforma integracyjna jest na tyle dużym przedsięwzięciem, że wymaga wsparcia na wysokim szczeblu w strukturze firmy) prace przy refactoringu platformy integracyjnej mogą generować koszty, które spowodują brak zakładanych oszczędności tworzenie usług na platformie integracyjnej jest relatywnie szybkie i proste, gdyż odbywa się za pomocą gotowych komponentów, których można używać jak klocków Lego; nie można jednak zastosować wielu zwinnych narzędzi wykorzystywanych przy tradycyjnym wytwarzaniu oprogramowania, trzeba napisać je od zera Zakładamy, że EAI zostało wdrożone w dużej korporacji posiadającej wielu dostawców, zaś platforma integracyjna rozwijana jest w ramach outsourcing-u. Rocznie realizowanych jest kilkadziesiąt projektów, zdarza się, że w ciągu miesiąca parę z nich toczy się równolegle, a ich obszary mogą na siebie zachodzić. Sumaryczny budżet projektów jest o co najmniej rząd wielkości większy od własnego budżetu platformy integracyjnej. Nadrzędnym celem EAI jest sprawne dostarczanie usług dla biznesu. Działania w obszarze EAI są żywotnie powiązane z funkcjonowaniem firmy, ale również są trudne. Z założenia platforma integracyjna musi radzić sobie z wieloma aplikacjami działającymi na wielu różnorodnych technologicznie systemach. O ile te wymagania są pokrywane przez gotowe adaptery EAI, inne aspekty techniczne również nie stanowią większego problemu, to prawdziwym wyzwaniem jest implementacja EAI rozpinającego się pomiędzy biznesem a IT. Platforma integracyjna wymaga dostosowania polityki korporacyjnej, odpowiedniej komunikacji pomiędzy jednostkami firmy oraz podziału odpowiedzialności. Dotychczasowe aplikacje biznesowe przestają być bytami niezależnymi a stają się częściami większych przepływów i procesów funkcjonujących w ramach platformy integracyjnej. EAI dotyka wielu technicznych i biznesowych aspektów. Projekty integracyjne wymagają modelowania biznesowego w dużo szerszym zakresie niż w przypadku pojedynczych aplikacji czy systemów. Również niezbędne są działania techniczne, 7

8 niskopoziomowe, wymagające szerokiego zakresu specjalistycznych umiejętności. Połączenie wysokopoziomowych aspektów biznesowych z niskopoziomowymi technicznymi jest istotnym czynnikiem sukcesu platformy integracyjnej. Różnorodność technologii oraz rozproszona natura EIA sprawia, że wdrożenia, monitorowanie oraz rozwiązywanie problemów wymaga połączenia umiejętności, które nie istnieją w jednostkach odpowiedzialnych za utrzymanie IT i/lub są rozproszone pomiędzy wiele podmiotów. 8

9 3. Koncepcje Rys. 3. Filary koncepcji EAI Na początku trzeba uświadomić sobie, że platforma integracyjna jest tworem na tyle dużym i ważnym, że niezbędne jest objęcie jej nadzorem IT Governance. Wraz z rozwojem EAI przez platformę zaczynają przebiegać kluczowe dla firmy procesy. Platforma staje się krytyczną dla biznesu. Biznes nie powinien pozwalać na powstanie takiej sytuacji, w której zależy od czynników poza bezpośrednią kontrolą firmy, tak więc objęcie obszaru EAI przez IT Governance jest oczywistą koniecznością. Nadzór nad platformą powinien zapewniać to, że rozwija się ona oraz że jest to rozwój we właściwym kierunku. Dyrektor wykonawczy oczekuje od EAI wsparcia i dostarczania rozwiązań dla zwiększenia wartości biznesu, szybkich i wysokiej jakości wdrożeń z minimalnym ryzykiem. Środki budżetowe wyasygnowane na inwestycje powinny przynosić mierzalny zwrot. EAI powinno być efektywne i produktywne a docelowo przyczyniać się do współtworzenia wartości firmy (w dojrzałej architekturze SOA nowe produkty tworzone są niskim kosztem za pomocą serwisów kompozytowych używających już istniejących serwisów atomowych). Zwinne EAI z punktu biznesu powinno dostarczać na czas usług wysokiej jakości. Nadzór nad EAI, konieczny do tego, aby platforma integracyjna spełniała swoje funkcje, wymaga odpowiedzialności osób zarządzających. Powinien on obejmować przywództwo (podejmowanie decyzji, wyznaczanie strategii), struktury organizacyjne, procesy zarządcze oraz aktywizację kluczowych uczestników. Kluczowe są tu pojęcia: decyzyjność i odpowiedzialność. EAI jest częścią IT zawieszoną pomiędzy jednostkami odpowiedzialnymi za eksploatację i wsparcie systemów, aplikacje biznesowe, planowanie, architekturę, polityki, bezpieczeństwo informacji, priorytetyzację projektów, analizę i zarządzanie ryzykami 9

10 operacyjnymi. Wzajemny zakres odpowiedzialności wymienionych jednostek, ich interakcje i wsparcie jednych dla drugich powinno być ściśle określone. IT Governance powinien stymulować całościowe spojrzenie na EAI. Przykładowo: przy rocznym zmierzonym wzroście platformy integracyjnej o 30% po 3 latach mamy ponad dwa razy więcej komponentów i przepływów. Ważny jest tu przymiotnik zmierzony bieżący stan powinien być monitorowany, powinny powstawać modele predykcji walidowane względem aktualnej sytuacji. Wraz z komponentami powinien być skalowany sprzęt (planowanie pojemności) i architektura. Skalowanie architektury oznacza jej refactoring, dostosowywanie jej długoterminowej wizji w oparciu o analizę bieżących wymagań (Service Strategy, Continual Service Improvement z ITIL). Brak refactoringu powoduje sięganie prawą ręką do lewej kieszeni a w dłuższej perspektywie utratę zarządzalności nad EAI. Szybki niekontrolowany wzrost bez położenia odpowiedniego nacisku na cykliczną analizę aktualnego stanu, jakość i udokumentowanie projektów może mieć opłakane skutki w sytuacji awarii w postaci braku wiedzy, o tym co się dzieje i braku kontroli nad sytuacją. Jeśli architektura nie jest zaplanowana do przetrwania pesymistycznych przypadków, to nie może nie przetrwać nawet tych realistycznych. Jeśli architektura nie jest zaplanowana przez architektów, specjalistów z różnych dziedzin, to platforma może runąć kiedyś jak domek z kart. Platforma integracyjna to sprzęt, system operacyjny, narzędzia i komponenty. Jeśli nie ma kontroli nad tym wszystkim, to nie ma kontroli nad niczym. Zarządzanie ryzykiem powinno być obecne we wszystkich działaniach operacyjnych, zapewniając zdolność do szybkiego raportowania o zagrożeniach i przystosowywania się do zmiennego środowiska ryzyka zewnętrznego i wewnętrznego. Ważne jest zrozumienie, że EAI to przedsięwzięcie ogólnofirmowe i tak też powinno być realnie traktowane. Żywiołowe podejście do platformy integracyjnej jakie czasami zdarza się w zwykłych zwinnych projektach jest niebezpieczne. W tym obszarze wszystko powinno zostać dobrze określone i regularnie sprawdzane czy nadal przystaje do przyjętych założeń. Ustaliliśmy, że podejścia formalne w postaci IT Governance są w EAI konieczne, spróbujmy teraz przeanalizować czy w poszczególnych obszarach, którymi (dla usystematyzowania) zajmuje się ITIL, można zastosować podejście zwinne i na czym powinno ono polegać. 10

11 3.1 Service Strategy Jednym z warunków brzegowych do rozważań o zwinności EAI było założenie, że w mamy wielu dostawców. Platforma integracyjna powinna być bytem w miarę jednorodnym, a co za tym idzie produkty wytwarzane przez dostawców powinny dostosowywać się do wspólnie wypracowanych standardów i wzorców. Usługi EAI są przekazywane przez dostawcę wraz z kodem źródłowym. Kod powinien być dostępny dla wszystkich dostawców w jednym centralnym repozytorium. Otwartość kodu ułatwia pisanie usług, które wchodzą w interakcje z danym serwisem mimo stosowania zasady luźnych powiązań znajomość wewnętrznych zasad działania danej usługi powinna przyczynić się do podniesienia jakości serwisu, który wchodzi z nią w interakcję. Właścicielem kodu powinna być firma, jego opiekunem dostawca. W celu wyeliminowania zagrożenia praktykami monopolistycznymi (vendor lock-in) i urzeczywistnieniu zasad zdrowej konkurencji należałoby przyjąć, że usługi wytworzone przez jednego dostawcę mogą być rozwijane przez innego. Dostawcy mogą wypracowywać własne standardy i wzorce, przedstawiać je na spotkaniach typu standing meeting, propagować je na innych dostawców i mieć wkład do bazy wiedzy firmy dostępnej dla dostawców i biznesu. Rys. 4. WSO2 Service Registry narzędzie typu repozytorium serwisów 11

12 Rys. 5 Graficzne projektowanie usług w Sun OpenESB Oprócz otwartego repozytorium kodu powinno istnieć otwarte repozytorium usług mające charakter zarówno techniczny jak i biznesowy, użyteczne dla analityków i dostawców. Znajomość dostępnych na platformie usług powinna przyczynić się do ich reużywalności. Przykład przyjętych standardów procesu dewelopmentu 1. Repozytorium SVN zawiera następujące linie kodu (katalogi) służące do separacji komponentów ze zwględu na status dewelopmentu: a. Produkcja (całe komponenty w wersjach zgodnych z tymi na środowisku produkcyjnym) b. Branches/nazwa_projektu (wszystkie komponenty w ramach projektu) i. Gałąź komponentu tworzona jest z produkcji lub najpóźniejszej gałęzi odpowiedniego komponentu ii. Po zakończeniu dewelopmentu, testów i wdrożeniu gałęzie komponentu scalane są z linią produkcji 12

13 c. Deployment (wszystkie artefakty niezbędne do wdrożenia danego projektu, kod komponentów dostosowany do aktualnych wersji produkcyjnych tak, żeby komponenty z linii deployment mogły zastąpić w trakcie wdrożenia kod z linii produkcji) i. Deployment po wdrożeniu jest migrowany do Produkcji 2. Deweloper zmieniając roboczą wersje kodu pomiędzy liniami wysyła raport z informacją o komponentach i sąsiednich zapisach kodu w ramach linii źródłowej i docelowej. 3. Przed migracją do linii Deployment następuje audyt wdrażanego kodu przeprowadzany przez dostawcę i/lub osobę nadzorującą projekt oraz osobę zajmującą się utrzymaniem/monitoringiem pod względem obsługi błędów, transakcyjności, persystentności komunikatów, obsługi duplikatów, logowania. Wykrycie błędów cofa projekt do etapu dewelopmentu. Z audytu tworzony jest raport z listą audytowanych przepływów. 4. W linii Deployment powinien znajdować się kod z wydzielonymi w repozytorium komponentu lub osobnym repozytorium testami jednostkowymi, integracyjnymi oraz testami regresji. 5. Kod z linii Deployment podlega testom na odizolowanym środowisku testowym odzwierciedlającym w jak najlepszym stopniu produkcyjne otoczenie rozwiązań integracyjnych. Artefakty EAI integrowane są z przygotowanym środowiskiem. Następuje przetestowanie kodu oraz wdrożenia. Testy poszczególnych przepływów powinny być zakończone akceptacją wszystkich systemów biorących udział w przepływie. Wdrożenie możliwe jest tylko po dostarczeniu przez dostawcę raportu potwierdzającego poprawne działanie wszystkich przepływów, w tym tych z testów regresji. Testy regresji opracowywane są w oparciu o testy jednostkowe i integracyjne wdrażanych wcześniej komponentów. W miarę rozwoju portfela usług w ramach architektury SOA duża liczba serwisów może stwarzać problem w ich zarządzaniu. Z czasem może pojawić się też zagrożenie vendor lock-in ze strony dostawcy oprogramowania middleware, na którym działa platforma integracyjna. Warto już na samym początku rozważyć federacyjną koncepcję SOA. 13

14 Koncepcja ta zakłada wydzielenie niezależnych od siebie domen. Domeny takie posiadają jasno zdefiniowane usługi oraz jasno określonych właścicieli biznesowych i technologicznych. Federacyjne podejście do SOA zmniejsza całościową złożoność pojawiającą się jako negatywny skutek rozwoju architektury. W procesie planowania usług powinien aktywnie uczestniczyć biznes, który zna swoje plany rozwojowe, architekci integracyjni oraz architekci infrastruktury (rozwój portfela usług może napotkać na ograniczenia pojemnościowe ze strony sprzętu, systemów operacyjnych, baz danych, itp.). Proces ten powinien być jasno zdefiniowany w ramach IT Governance. Warto uświadomić sobie, że każda usługa ma swój cykl życia jeśli przestała spełniać wymagania postawione w momencie jest tworzenia prawdopodobnie powinna zostać wycofana. Każda usługa powinna być zinwentaryzowana i posiadać właściciela biznesowego, właściciela procesu, właściciela technicznego. W strategii usług EAI ważnym elementem jest zarządzanie finansami. Platforma integracyjna nie posiada nieograniczonego budżetu. Implikacje są dwie: nie zawsze mogą powstawać rozwiązania najlepsze pod względem architektury, czy zastosowanych technologii, jeśli są one za drogie należy wtedy przyjąć założenie (najlepiej potwierdzone w ramach IT Governance), że w przypadku przyszłych projektów w danym obszarze dysponujących większymi środkami budżetowymi należy obowiązkowo dokonać refactoringu, który przeciwdziała degradacji jakości usług jak i architektury całej platformy. Drugi wniosek wynikający z ograniczeń budżetowych to zachęta do zastosowania zasady KISS ( Keep it simple, stupid ) promowanej przez extreme Programming 2. Na prosty projekt zawsze potrzeba mniej czasu i pieniędzy niż na złożony. Każda usługa powinna być wykonana minimalnym nakładem środków potrzebnych do jej wdrożenia i prawidłowego działania. Nie należy projektować zbyt złożonych serwisów, co do których nie ma gwarancji niezawodnego działania i skalowania. W celu oceny złożoności można używać takich kryteriów jak możliwości przetestowania, łatwość zrozumienia i wytłumaczenia projektu, łatwość odnalezienia danej funkcjonalności w kodzie/zestawie komponentów. Projekty, których nie można dokładnie przetestować (włączając obsługę błędów i sytuacji awaryjnych, niestandardowych scenariuszy) nie powinny być w ogóle wykonywane. Preferowane są projekty, dla których da się stworzyć automatycznie 2 14

15 wykonywalne testy jednostkowe oraz testy akceptacyjne. Prosty design oznacza także unikanie generyczności na siłę, aby za wszelką cenę uzyskać reużywalność usług. Pośrednio do zasady KISS odwołuje się Kanban, który postuluje tworzenie nowych funkcjonalności tylko w przypadku kiedy są one realnie potrzebne z biznesowego punktu widzenia (są one zdefiniowane jako wymagania użytkownika końcowego). Tworzenie danego artefaktu technicznego wyzwalane jest przez wymaganie biznesowe na zasadzie wstecznej analizy zależności. Z faktu, że rozwój platformy integracyjnej jest procesem ustawicznym, ale nie jednorodnym wynika problem z dostępnością zespołu dostawcy i/lub jakością deweloperów, a co za tym idzie jakością usług. Jeśli popyt ze strony firmy jest w uznaniu dostawcy niewystarczający zapewne dokona on relokacji swojego zespołu do innego klienta. Firma i dostawca powinni zawczasu informować się planowanych poczynaniach w zakresie popytu i podaży. Być może bezpiecznym rozwiązaniem jest zatrudnienie przez firmę jednego lub dwóch deweloperów, którzy w razie niedostępności zespołu dostawcy byliby w stanie szybko dokonać w kodzie małych zmian typu Change Request. Z faktu, że dany dostawca nie jest stale dostępny należy zwrócić uwagę na znaczenie baz wiedzy czy repozytorium serwisów. Wiedza w jaki sposób funkcjonuje dana usługa nie powinna być tracona wraz z odchodzącym deweloperem. Oprócz relacji popytu i podaży między firmą i dostawcą te same procesy zachodzą między EAI a klientem wewnętrznym. Jeśli szacowane wydatki projektowe są zbyt duże dany interesariusz może dojść do wniosku, że jest w stanie stworzyć usługę z pominięciem platformy integracyjnej. Wtedy obok pięknie zaprojektowanego i wdrożonego SOA może powstać makaron integracyjny skutecznie generujący problemy platformie integracyjnej (przykładowo: istnieje przepływ przechodzący przez platformę integracyjną oraz jego odpowiednik zrobiony z jej pominięciem; w przypadku awarii tego drugiego winne będzie EAI a szukanie problemu czasochłonne i nie przynoszące rezultatów). Platforma integracyjna nie powinna na siłę akceptować projektów, dla których z racji swojej technologii dedykowanym rozwiązaniem. Warunki akceptacji i odrzucania projektów powinny być jasno zdefiniowane w ramach IT Governance. 15

16 3.2 Service Design Tradycyjne podejście do EAI zakłada planowanie projektu z założeniem, że proces i wymagania biznesowe są najważniejsze i absolutnie konieczne jest trzymanie się przyjętego planu i kosztorysu. Podejście to sprawdza się kiedy wymagania pozostają statyczne. Rzeczywistość jednak pokazuje, że w korporacji posiadającej wiele niezależnych systemów z własnymi cyklami życia i cyklami projektowymi, która również musi się podporządkować zmieniającym się regulacjom prawnym i reagować na zmiany zachodzące na rynku, podejście do projektów EAI musi być dynamiczne. Podejścia zwinne bazują na dobrze zdefiniowanych regułach postępowania wyznaczających procesy, które mogą być adaptowane do zmieniających się warunków. Metodyki zwinne zakładają iteracyjny dewelopment, łatwość projektowania, partnerstwo z użytkownikiem końcowym/biznesowym oraz skrupulatne testowanie. Proces planowania jest bardziej elastyczny. Wymagania biznesowe rozbite są na pojedyncze funkcjonalności, które mogą być realizowane w krótkim czasie jakim jest jedna iteracja. Duży i złożony projekt może być rozbity na fazy, a te na iteracje. Takie podejście pozwala na oszacowanie w każdym momencie trwania projektu czasu i środków niezbędnych do jego zakończenia. Zakładając, że 80% zakresu projektu daje się zrealizować w 20% czasu, podejście iteracyjne pozwala na wcześniejsze biznesowe uruchomienie projektu, a w przypadku wystąpienia obiektywnych problemów blokujących realizację projektu pozwala na oddanie do użytku obciętej funkcjonalności, podczas gdy przy metodyce formalne projekt zostałby wstrzymany na dobre lub zostałby wyrzucony do kosza. Sytuacje współbieżnego toczenia się projektów oraz ich wzajemnych zależności są na porządku dziennym. Projekty dotykające tych samych obszarów biznesowych wzajemnie się blokują lub sobie przeszkadzają. Stosując podejście zwinne można z tych projektów stworzyć jeden meta-projekt, gdzie chronologicznie zdefiniowane wymagania biznesowe opatrzone odpowiednimi priorytetami zostaną zmapowane na funkcjonalności przeznaczone do wykonania w kolejnych iteracjach. Można potraktować to jako specyficzne zastosowanie wzorca scather-gather, gdzie projekty rozbite są na części składowe służące następnie do stworzenia meta-projektu. Podczas gdy prowadzony metodykami formalnymi duży projekt trwa rok (w trakcie którego mogą zmienić się zupełnie realia prawne lub rynkowe) i jego sukces albo porażka są wiadome dopiero na końcu testów akceptacyjnych lub w pesymistycznym przypadku po wdrożeniu, metodyka zwinna zapewnia lepszą widoczność sytuacji. Każda iteracja zawiera analizę, projektowanie, kodowanie 16

17 oraz testowanie i wnosi do projektu działające funkcjonalności. W przypadku kiedy kolejna iteracja nie wnosi nowej funkcjonalności można szybko zareagować i wdrożyć w życie zarządzanie zagrożeniem. W dużym formalnym projekcie problem może być widoczny z dużym opóźnieniem a na odpowiednią reakcję może być za późno jeśli projekt zostanie ukończony nastąpi to z przekroczeniem czasu i budżetu. Iteracyjne dostarczanie małych funkcjonalności pozwala na ustawiczne testowanie systemu w bieżącym stanie rozwoju. Architektura rozwiązania może być odpowiednio wcześniej zmieniona, jeszcze na etapie kiedy jest to możliwe bez wykładniczego wzrostu nakładów. Podobnie na bieżąco wiadomo jak powinna wyglądać infrastruktura IT przeznaczona dla danego projektu. Zwinne podejście do EAI wymaga bliskiego partnerstwa z biznesem (zarówno właścicielami biznesowymi projektów jak i użytkownikami końcowymi). Bez odpowiednich relacji zwinna metodyka nie ma racji bytu. Lista wymagań nie może być objawiona platformie integracyjnej jak 10 przykazań wyrytych na kamiennych tablicach z nieobecnym (w czasie trwania projektu) autorem. Podejście zwinne zakłada ścisłą współpracę. Jest to na tyle kluczowy element procesu, że powinien być on głośno i wyraźnie zakomunikowany wszystkim, najlepiej poprzez IT Governance, tak żeby nie było wątpliwości co do jego znaczenia i wymagalności. Współpraca pozwala na szybkie odpowiedzi zwrotne biznesu na zaprezentowaną funkcjonalność z możliwością skorygowania wymagań. Zespół projektowy może na bieżąco informować o konsekwencjach przyjętego w projekcie kierunku. Dzięki dwustronnej komunikacji mogą być podejmowane wspólne decyzje, które prowadzą do realizacji celów biznesowych postawionych przed projektem. Bieżąca komunikacja z biznesem zapewnia także, że nie powstaną niepotrzebne funkcjonalności, które byłby nieużywane, a za które trzeba by było zapłacić. Wszelkie zmiany w projekcie przyczyniają się na korzyść firmy, a nie odwracają się przeciwko niej. Oprócz biznesu projekt powinny wspierać jednostki odpowiedzialne za bezpieczeństwo, infrastrukturę, dostępność, ciągłość usług IT, pojemność. Zabezpieczenie komunikacji między systemami za pomocą szyfrowania/kryptografii ma istotny wpływ na wydajność i może powodować problemy pojemnościowe, może w danym projekcie nie jest ono konieczne lub da się je zastąpić alternatywnym rozwiązaniem np. wydzielenie izolowanych segmentów sieciowych. Jak widać w projekcie potrzebni są specjaliści z wielu dziedzin a ich obecność jest niezbędna do wypracowania najlepszego rozwiązania. 17

18 Ważnym zagadnieniem jest eliminacja błędów poprzez skrupulatne iteracyjne testowanie. W przypadku EAI mogą nie istnieć gotowe narzędzia do zautomatyzowanych testów jednostkowych, obciążeniowych czy akceptacyjnych, jednak zwinne podejście postuluje konieczność ich zastosowania. W takim przypadku narzędzia powinny zostać stworzone wraz z pierwszym projektem, a koszt inwestycji nie powinien przekroczyć kosztu projektu. Rys. 6. CruiseControl narzędzie do automatyzacji testów Przykład zastosowania zasady KISS w tworzeniu narzędzi do testowania "Przechodzimy" aplikację webową w przeglądarce Mozilla Firefox wyposażonej we wtyczkę "Live HTTP headers" i kopiujemy dane wysyłane formularzem. Dane te wkleimy potem do linii poleceń uniksowego narzędzia wget. WP_URL="http:// :8080/app/AppServlet" COOKIE="cookie.dat" WGET_CMD="wget --timeout=15 --keep-session-cookies --save-cookies=$cookie --quiet $WP_URL -O -" > $COOKIE RUNNING=$(ps uax grep -c nazwa_skryptu.sh) 18

19 [[ $RUNNING -gt 3 ]] && echo "Poprzednie wywolanie skryptu wisi" && exit 1 RES=$($WGET_CMD --postdata="user=jan.kowalski&password=lubieciasteczka&action=login" grep -c "Zalogowany: ") echo "Test logowania. Wynik: $RES" RES=$($WGET_CMD --load-cookies=$cookie --post-data="action=createprocess&action_params=...&state=" grep -c "Nowy proces") echo "Zaladowanie procesu. Wynik: $RES" RES=$($WGET_CMD --load-cookies=$cookie --postdata="action=next&action_params=..." grep -c "Dane zapisano") echo "Wynik procesu poprawny?: $RES" RES=$($WGET_CMD --load-cookies=$cookie --post-data="action=save-andclose&action_params=..." grep -c "Zakonczono proces") echo "Zamkniecie procesu. Wynik: $RES" RES=$($WGET_CMD --load-cookies=$cookie --post-data="action=logout" grep -c "Wylogowano uzytkownika") echo "Wylogowanie. Wynik: $RES" Rys. 7. Grinder dedykowane narzędzie do testów obciążeniowych Proces testowania powinien być częsty i rygorystyczny. Na podstawie testów jednostkowych i akceptacyjnych powinny powstawać zestawy testów regresji. Ich istnienie pozwala na bezpieczny refactoring oraz wprowadzanie zmian i jest kluczowe dla przebiegu dynamicznego projektu EAI. Zespół projektowy ma bardzo duże szanse na wykrycie błędów w kodzie, a te pojawiają się zawsze i w każdym projekcie. Wczesne wykrycie błędów minimalizuje problemy w późniejszy stadium zaawansowania dewelopmentu. Zastosowanie 19

20 metodyki zwinnej minimalizuje ryzyko oraz zwiększa stopę zwrotu z inwestycji poprzez szybsze dostarczanie projektów. Należy pamiętać, że projekt nie jest zawieszony w próżni i działa w ramach istniejącej infrastruktury i architektury IT. Przy każdy projekcie powinna następować analiza, czy obecna architektura i infrastruktura w dalszym ciągu mają szanse na skalowanie się. Jeśli nie to należy odpowiednio wcześnie reagować nie pozwalając na powstawanie wąskich gardeł. W projekcie EAI niezbędna jest obecność architekta. Architekt to osoba odpowiedzialna za modelowanie aplikacji, infrastruktury, procesu dewelopmentu. Przykładowo: metodyka MSF for CMMI definiuje dwie role architektów - Solution Architect i Intrastructure Architect. Architekt to osoba wyznaczająca standardy, wzorce i dobre praktyki, wyznaczająca kierunek. Architekt asystujący przy projekcie na podstawie własnego doświadczenia i znajomości technologii proponuje najbardziej odpowiednie rozwiązania. Architekt i lead developer/projektant to nie to samo. Architekt dokonuje ewaluacji nowych technologii, ale zawsze preferuje stabilne rozwiązania. W ramach zarządzania dostawcami firma powinna mieć realny wpływ na skład zespołu integracyjnego. Członkowie zespołu powinni znać wzorce, technologie i odpowiednie zasady postępowania. Zespół EAI nie powinien być nadmiernie rozbudowany, ale powinien posiadać specjalistów z wielu dziedzin (bazy danych, systemy operacyjne, infrastruktura sieciowa, technologie i aplikacje występujące w integrowanych systemach). Często zespół będzie musiał wykonywać samodzielnie te czynności, które w mniejszych projektach zlecane są jednostkom wspierającym IT. Sumaryczne wymagania dla zespołu EAI: J2EE Servlety JSP EJB WS JMS UI Swing DHTML CSS 20

21 Serwery aplikacyjne + infrastruktura Tomcat WebLogic Apache + mod_proxy WebMethods/Tibco/WebSphere Narzędzia Eclipse Grails Programowanie C/C++/C# UNIX POSIX.NET Znajomość protokołów i formatów TCP/IP HTML + typowe nagłówki HTTP POP3 SMTP NTLM AT (modem) XML XSLT XSD WSDL UML Programowanie shellowe UNIX Bash, sed, awk Inżynieria wsteczna i diagnozowanie problemów Dekompilacja, JAD, wzorzec projektowy wrapper/proxy, podmiana klas Strace, objdump Diagnostyka JMS-a za pomocą narzędzia Hermes Profilowanie aplikacji (YKP) Tuningowanie maszyny wirtualnej (w tym GC) Sun JVM, BEA JRockit Serwery Sun Bazy danych (dewelopment, częściowo administracja) MSSQL Oracle PostgreSQL 21

22 Administracja systemami operacyjnymi i narzędziami do pracy grupowej Solaris Windows 2003/2008 RedHat/Fedora SuSE VMware Subversion Wiki Zagadnienia koncepcyjne Inżynieria oprogramowania Wzorce projektowe Wzorce projektowe EAI SOA Wzorce projektowe SOA BPM Testowanie aplikacji HCI, projektowanie UI Balancing, fail-over System operacyjny UNIX (planista, zarządzanie pamięcią, libc) Zwinne podejścia do wytwarzania oprogramowania (extreme Programming, Scrum) Bezpieczeństwo Znajomość bibliotek, technologii, technik, narzędzi, itp. Xerces, DOM XStream XMLSpy JUnit Selenium IDE Pobieżna znajomość silników przeglądarek WWW (IE, Firefox, KHTML, Opera) Statystyka matematyczna + StatGraphics lub R 22

23 3.3 Service Transition Biorąc pod uwagę iteracyjny charakter rozwoju oprogramowania i cykliczne powstawanie wersji stabilnych w projekcie prowadzonym za pomocą zwinnej metodyki, czynności związane ze wdrożeniem usługi (planowanie i przygotowanie wersji, budowa i testy, testy usług i pilot, planowanie i przygotowanie wdrożenia, wdrożenie, przegląd i zamknięcie) powinny być łatwiejsze do przeprowadzenia oraz obarczone mniejszym ryzykiem niż w przypadku podejścia formalnego. Ze względu na konieczność zachowania biznesowej ciągłości działania firmy proces wdrożenia może być zdefiniowany formalnie i powinien korzystać ze wszystkich technologicznych możliwości zapewniających failover czy wdrożenie typu zero downtime. Wdrożenia powinny być analizowane i ocenianie w ramach Continual Service Improvement. Rys. 8. Load balancer pozwalający za pomocą wag na wybór aktywnego w sieci serwisu 23

24 Przykład zdefiniowanego procesu wdrożenia 1. Wdrożenie wykonywane jest przez utrzymanie platformy integracyjnej. 2. Dostawca ustala wynikowe artefakty kodu, które podlegać będą wdrożeniu. Wszystkie artefakty do wdrożenia (włączając w to paczki do deploymentu) umieszczane są w osobnej gałęzi SVN z linii Deployment: nazwawdrozenia_expected_yyyymmdd. Lista wdrażanych artefaktów przesyłana jest do akceptacji. 3. Deweloperzy dostarczają instrukcję wdrożeniową i administracyjną (zawierające opis możliwych do wystąpienia błędów związanych z aktualnym wdrożeniem i sposobu reakcji na nie; instrukcje powinny zawierać schemat zależności między wdrażanymi systemami i komponentami) dla utrzymania. Utrzymanie akceptuje lub odrzuca instrukcję, biorąc pod uwagę to, że jest ono odpowiedzialne za sukces wdrożenia i powinno posiadać niezbędną wiedzę do jego przeprowadzenia. Instrukcje w kolejnym kroku akceptuje lub odrzuca kierownik projektu. 4. Wdrożenie poprzedza równoległe zadeployowanie artefaktów kodu z użyciem symlinków Unix do komponentów, nowych wersji pakietów i procedur bazodanowych z użyciem aliasów, ewentualnie nowych wersji obiektów JMS z użyciem mostków łączących bieżący temat/kolejkę JMS z nową/starą wersją. Wyżej wymienione postępowanie ma na celu dostarczenie możliwości szybkiego rollbacku wdrożenia. 5. Aktywacja wdrożenia polega na przepięciu wersji komponentów oraz przetestowaniu działania produkcyjnego po czym następuje commit lub rollback wdrożenia. Aktywacja może nastąpić tylko w częsci wspólnej okien serwisowych systemów, których dotyczy wdrożenie komponentów platformy integracyjnej. 6. Prace związane z aktywacją wdrożenia nie mogę trwać dłużej niż 30 minut. Jeżeli 5 minut przed czasem decyzji commit/rollback nie ma szans na commit następuje rollback wdrożenia. Decyzję o rollbacku podejmuje kierownik projektu. Ograniczenia na czasy commit/rollback mogą być zmienione w wyniku decyzji kierownika projektu. 7. Dostawca dostarcza raport z wdrożenia z opisem ewentualnych problemów podczas wdrożenia. Raport konfrontowany jest z raportem z testów. 24

25 Wdrożenie i zakończenie okresu stabilizacji powinno wiązać się z przekazaniem dokumentacji do bazy wiedzy/repozytorium usług. Metodyki zwinne zakładają, że kod sam się dokumentuje i generują niewielką ilość dokumentacji w przypadku EAI tym niezbędnym minimum powinien być kontekst biznesowy usługi, techniczny i biznesowy opis przepływów/procesów, opis (lub diagram) interakcji między komponentami EAI oraz interfejsy serwisów umieszczane w repozytorium usług. Tworzenie dokumentacji może być automatyczne jeśli narzędzia do tworzenia procesów platformy integracyjnej posiadają możliwość tworzenia adnotacji (te ostatnie przydatne są także jednostkom IT realizującym utrzymanie, które analizując problemy mają kod i opis procesów w jednym miejscu). Wdrażany projekt powinien mieć zdefiniowane parametry SLA, biorące pod uwagę wymagania podłączonych systemów wobec platformy integracyjnej, co do jej dostępności oraz obciążenia EAI generowane przez podłączone systemy. Nowoczesne produkty ESB posiadają wbudowane możliwości kontrolowania SLA w czasie rzeczywistym za pomocą modułów mediacji, wirtualizacji usług czy BAM (Business Activity Monitoring). Pomiar SLA jest kluczowy w procesie zarządzania pojemnością. Niektóre pakiety ESB posiadają narzędzia do egzekwowania zdefiniowanych SLA, dzięki którym można chronić platformę integracyjną przed klientami realnie dokonującymi ataku Denial of Service lub skutecznie degradującymi wydajność EAI. Mierzone dane powinny być zbierane i służyć do opracowywania prognoz możliwości skalowania się platformy. Zawczasu przewidziane wąskie gardło powinno zostać wyeliminowane w drodze zmian architektury i/lub infrastruktury. Brak proaktywnej polityki w tym obszarze może zemścić się w przypadku nagłego wzrostu obciążenia danego przepływu i skutkować awarią. Obsługa SLA przez platformę integracyjną jest niewątpliwie sporą wartością dodaną i warto zastanowić się nad uaktualnieniem obecnie używanego produktu EAI do ESB, jeśli producent middleware-u posiada szynę w swojej ofercie. 25

26 3.5 Service Operation Ponieważ platforma integracyjna obsługuje przepływy przechodzące przez całą firmę i zazwyczaj posiada dobre logowanie przechodzących przez nią danych, staje się naturalnym winowajcą we wszystkich incydentach oraz równocześnie jedyną jednostką, która może dobrze zdiagnozować miejsce występowania problemu. Obszar EAI wymaga konsolidacji sporego zakresu umiejętności i dlatego jednostka odpowiedzialna za eksploatację platformy integracyjnej nie może być tożsama z IT Operations powinien być to dedykowany zespół specjalistów z deweloperem dostępnym w razie zaistnienia potrzeby na wyłączność (może być to funkcja rotacyjna). Incydenty zgłaszane do utrzymania EAI powinny być cyklicznie analizowane (np. w dwumiesięcznych okresach czasu) i stanowić wkład do Continual Service Improvement. Powtarzające się incydenty w danym przepływie mogą świadczyć o jego błędnym zaprojektowaniu, nie wykrytych na etapie testowania błędach lub problemach wydajnościowych. O przeprocesowane incydenty powinna być uaktualniana baza wiedzy. Rys. 9. Narzędzia do monitorowania dostarczane wraz z maszyną wirtualną Javy Oracle JRockit 26

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1 Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących

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

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

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

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

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

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

Bardziej szczegółowo

Wdrożenie 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

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

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

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

Bardziej szczegółowo

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

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

Bardziej szczegółowo

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

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

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

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

Bardziej szczegółowo

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

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

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

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

Egzamin ITIL Foundation

Egzamin ITIL Foundation Egzamin ITIL Foundation Przykładowy arkusz egzaminacyjny A, wersja 5.1 Test wielokrotnego wyboru (tylko jedna odpowiedź jest prawidłowa) Instrukcja 1. Należy udzielić odpowiedzi na wszystkie 40 pytań.

Bardziej szczegółowo

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

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

Bardziej szczegółowo

PureSystems zautomatyzowane środowisko aplikacyjne. Emilia Smółko Software IT Architect

PureSystems zautomatyzowane środowisko aplikacyjne. Emilia Smółko Software IT Architect PureSystems zautomatyzowane środowisko aplikacyjne. Emilia Smółko Software IT Architect Wbudowana wiedza specjalistyczna Dopasowane do zadania Optymalizacja do aplikacji transakcyjnych Inteligentne Wzorce

Bardziej szczegółowo

REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI

REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI WYTYCZNE DO MODELU DANIEL WOJEWÓDZKI Rekomendacje dotyczące Platformy Zarządzania Kompetencjami System adresowany do małych przedsiębiorstw do

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

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

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

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

Sposób funkcjonowania

Sposób funkcjonowania Stratus Avance został zaprojektowany w sposób, który w przypadku wystąpienia awarii ma zminimalizować czas przestoju i zapobiec utracie danych. Jednocześnie rozwiązanie ma być tanie i łatwe w zarządzaniu.

Bardziej szczegółowo

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan wdrożenia M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... 3 1.2 Zakres........................................

Bardziej szczegółowo

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów

Bardziej szczegółowo

OSGi Agata Hejmej 4.05.2009

OSGi Agata Hejmej 4.05.2009 OSGi Agata Hejmej 4.05.2009 Plan prezentacji Co to jest OSGi Jakie problemy rozwiązuje Opis standardu Przykładowa aplikacja Podsumowanie korzyści Co to jest OSGi? Standard, który pozwala na tworzenie wysoce

Bardziej szczegółowo

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42 SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH info@prointegra.com.pl tel: +48 (032) 730 00 42 1. WPROWADZENIE... 3 2. KORZYŚCI BIZNESOWE... 4 3. OPIS FUNKCJONALNY VILM... 4 KLUCZOWE FUNKCJE

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

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji. Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Aurea BPM. Unikalna platforma dla zarządzania ryzykiem Warszawa, 25 lipca 2013

Aurea BPM. Unikalna platforma dla zarządzania ryzykiem Warszawa, 25 lipca 2013 Aurea BPM Unikalna platforma dla zarządzania ryzykiem Warszawa, 25 lipca 2013 Agenda 1. Podstawowe informacje o Aurea BPM 2. Przykłady projektów w obszarze minimalizacji skutków zagrożeń 3. Aurea BPM dla

Bardziej szczegółowo

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

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

Bardziej szczegółowo

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój

Bardziej szczegółowo

JAK TO DOBRZE ZROBIĆ 5-06-2013

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

Bardziej szczegółowo

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

Web frameworks do budowy aplikacji zgodnych z J2EE

Web frameworks do budowy aplikacji zgodnych z J2EE Web frameworks do budowy aplikacji zgodnych z J2EE Jacek Panachida promotor: dr Dariusz Król Przypomnienie Celem pracy jest porównanie wybranych szkieletów programistycznych o otwartym kodzie źródłowym

Bardziej szczegółowo

Rozwiązanie Compuware dynatrace

Rozwiązanie Compuware dynatrace Rozwiązanie Compuware dynatrace COMPUWARE DYNATRACE... 3 2 COMPUWARE DYNATRACE Narzędzie Compuware dynatrace oparte jest o unikatową technologię agentową, która pozwala na dogłębną analizę stanu aplikacji

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

GLOBAL4NET Agencja interaktywna

GLOBAL4NET Agencja interaktywna Sklep internetowy Magento dla Rotom Polska Strona1 System B2B dla Rotom Polska Rotom jest jednym z czołowych dystrybutorów palet drewnianych, opakowań oraz nośników logistycznych dla przedsiębiorstw w

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

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

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

Compuware Changepoint. Portfolio Management Tool

Compuware Changepoint. Portfolio Management Tool Compuware Changepoint Portfolio Management Tool Compuware Changepoint Zintegrowane Zarządzanie Portfelem IT W dzisiejszym świecie czołowi użytkownicy IT podejmują inicjatywy dopasowania IT do strategii

Bardziej szczegółowo

Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g

Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g Szkolenie: Budowa aplikacji SOA/BPM na platformie Oracle SOA Suite 11g Opis szkolenia: Termin SOA, czyli Service Oriented Architecture, oznacza architekturę systemów informatycznych opartą o usługi. Za

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

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

OBIEG INFORMACJI I WSPOMAGANIE DECYZJI W SYTUACJACH KRYZYSOWYCH

OBIEG INFORMACJI I WSPOMAGANIE DECYZJI W SYTUACJACH KRYZYSOWYCH OBIEG INFORMACJI I WSPOMAGANIE DECYZJI W SYTUACJACH KRYZYSOWYCH AGENDA Prezentacja firmy Tecna Informacja i jej przepływ Workflow i BPM Centralny portal informacyjny Wprowadzanie danych do systemu Interfejsy

Bardziej szczegółowo

DOKUMENT INFORMACYJNY COMARCH BUSINESS INTELLIGENCE:

DOKUMENT INFORMACYJNY COMARCH BUSINESS INTELLIGENCE: DOKUMENT INFORMACYJNY COMARCH BUSINESS INTELLIGENCE: JAKIE PROBLEMY ROZWIĄZUJE BI 1 S t r o n a WSTĘP Niniejszy dokument to zbiór podstawowych problemów, z jakimi musi zmagać się przedsiębiorca, analityk,

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

ŚCIEŻKA: Zarządzanie projektami

ŚCIEŻKA: Zarządzanie projektami ŚCIEŻKA: Zarządzanie projektami Ścieżka dedykowana jest każdej osobie, która chce rozwijać siebie i swoją organizację - w szczególności: Kadrze menedżerskiej i kierowniczej przedsiębiorstw Kierownikom

Bardziej szczegółowo

Krótka Historia. Co to jest NetBeans? Historia. NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły. Paczki do NetBeans.

Krótka Historia. Co to jest NetBeans? Historia. NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły. Paczki do NetBeans. GRZEGORZ FURDYNA Krótka Historia Co to jest NetBeans? Historia Wersje NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły NetBeans Profiler Narzędzie do projektowania GUI Edytor NetBeans

Bardziej szczegółowo

Piotr Krząkała. Dyrektor Handlowy ds. Kluczowych Klientów

Piotr Krząkała. Dyrektor Handlowy ds. Kluczowych Klientów Piotr Krząkała Dyrektor Handlowy ds. Kluczowych Klientów Strategia firmy Każda organizacja działająca we współczesnym biznesie powinna posiadać określoną strategię działania i na tej bazie budować system

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

Security Master Class

Security Master Class Security Master Class Platforma kompleksowej analizy zdarzeń Linux Polska SIEM Radosław Żak-Brodalko Senior Solutions Architect Linux Polska sp. z o.o. Podstawowe problemy Jak pokryć lukę między technicznym

Bardziej szczegółowo

Usługi analityczne budowa kostki analitycznej Część pierwsza.

Usługi analityczne budowa kostki analitycznej Część pierwsza. Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.

Bardziej szczegółowo

Tools for (Java) Developers. by Mirosław Żyszczyński

Tools for (Java) Developers. by Mirosław Żyszczyński Tools for (Java) Developers by Mirosław Żyszczyński Agenda Wstęp / Cel wykładu Opis problemu programistów Etapy tworzenia aplikacji Przegląd etapów oraz narzędzi Confluence JIRA + JIRA Agile SVN FishEye/Crucible

Bardziej szczegółowo

Rozpoczęcie, inicjacja (ang. inception

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

Bardziej szczegółowo

Referat pracy dyplomowej

Referat pracy dyplomowej Referat pracy dyplomowej Temat pracy: Wdrożenie intranetowej platformy zapewniającej organizację danych w dużej firmie na bazie oprogramowania Microsoft SharePoint Autor: Bartosz Lipiec Promotor: dr inż.

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

Szczegółowy opis przedmiotu zamówienia

Szczegółowy opis przedmiotu zamówienia Załącznik nr 2 do Zapytania Ofertowego nr 07/04/IT/2016 Szczegółowy opis przedmiotu zamówienia Utrzymanie i rozwój systemów GREX, SPIN, TK, AMOC, Obsługa Rewidentów 1 SPIS TREŚCI Wprowadzenie... 3 1. Specyfikacja

Bardziej szczegółowo

Ekspert MS SQL Server Oferta nr 00/08

Ekspert MS SQL Server Oferta nr 00/08 Ekspert MS SQL Server NAZWA STANOWISKA Ekspert Lokalizacja/ Jednostka organ.: Pion Informatyki, Biuro Hurtowni Danych i Aplikacji Wspierających, Zespół Jakości Oprogramowania i Utrzymania Aplikacji Szczecin,

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

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

www.streamsoft.pl Katalog rozwiązań informatycznych dla firm produkcyjnych

www.streamsoft.pl Katalog rozwiązań informatycznych dla firm produkcyjnych www.streamsoft.pl Katalog rozwiązań informatycznych dla firm produkcyjnych Obserwować, poszukiwać, zmieniać produkcję w celu uzyskania największej efektywności. Jednym słowem być jak Taiichi Ohno, dyrektor

Bardziej szczegółowo

Case Study: Migracja 100 serwerów Warsaw Data Center z platformy wirtualizacji OpenSource na platformę Microsoft Hyper-V

Case Study: Migracja 100 serwerów Warsaw Data Center z platformy wirtualizacji OpenSource na platformę Microsoft Hyper-V Case Study: Migracja 100 serwerów Warsaw Data Center z platformy wirtualizacji OpenSource na platformę Microsoft Hyper-V Warszawa, 6 lutego 2014 www.hypermixer.pl 01 1 2 3 4 Rynkowe wyzwania Poszukiwania

Bardziej szczegółowo

Dlaczego modele architektoniczne to zamało? Wprowadzeniedo ładu architekturykorporacyjnej

Dlaczego modele architektoniczne to zamało? Wprowadzeniedo ładu architekturykorporacyjnej Dlaczego modele architektoniczne to zamało? Wprowadzeniedo ładu architekturykorporacyjnej Dr hab. Andrzej Sobczak, prof. SGH, Kierownik Zakładu Systemów Informacyjnych, Katedra Informatyki Gospodarczej

Bardziej szczegółowo

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Małgorzata Barańska Wydział Informatyki i Zarządzania, Politechnika Wrocławska Beata Laszkiewicz Wydział

Bardziej szczegółowo

Agile Project Management

Agile Project Management Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...

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

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

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

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

Bardziej szczegółowo

Testujemy dedykowanymi zasobami (ang. agile testers)

Testujemy dedykowanymi zasobami (ang. agile testers) Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania

Bardziej szczegółowo

III Etap konkursu TWOJA FIRMA TWOJA SZANSA NA SUKCES

III Etap konkursu TWOJA FIRMA TWOJA SZANSA NA SUKCES PROTECT DNA OF YOUR BUSINESS BUSINESS CONTINUITY INCIDENT AND RISK MANAGEMENT REAL TIME ENTERPRISE III Etap konkursu TWOJA FIRMA TWOJA SZANSA NA SUKCES Warszawa 11.05.2011 Projekt współfinansowany przez

Bardziej szczegółowo

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne.

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne. Załącznik nr 1a do Zapytania ofertowego nr POIG.08.02-01/2014 dotyczącego budowy oprogramowania B2B oraz dostawcy sprzętu informatycznego do projektu pn. Budowa systemu B2B integrującego zarządzanie procesami

Bardziej szczegółowo

Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne

Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne Dobre praktyki w doborze technologii rozwiązań informatycznych realizujących usługi publiczne Rafał Czubik Krzysztof Komorowski IBM 2008 IBM Corporation Metodyka jest ważna Procesy i moduły Obszary decyzyjne

Bardziej szczegółowo

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji. Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie

Bardziej szczegółowo

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI

Zarządzaj projektami efektywnie i na wysokim poziomie. Enovatio Projects SYSTEM ZARZĄDZANIA PROJEKTAMI Sprawne zarządzanie projektami Tworzenie planów projektów Zwiększenie efektywności współpracy Kontrolowanie i zarządzanie zasobami jak również pracownikami Generowanie raportów Zarządzaj projektami efektywnie

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

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci

UNIX: architektura i implementacja mechanizmów bezpieczeństwa. Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci UNIX: architektura i implementacja mechanizmów bezpieczeństwa Wojciech A. Koszek dunstan@freebsd.czest.pl Krajowy Fundusz na Rzecz Dzieci Plan prezentacji: Wprowadzenie do struktury systemów rodziny UNIX

Bardziej szczegółowo

Elektroniczna Księga Wieczysta

Elektroniczna Księga Wieczysta Elektroniczna Księga Wieczysta Aspekty wdrażania systemu informatycznego świadczącego usługi drogą elektroniczną Robert Ciurkot Dyrektor Departamentu Konsultingu Grupa Bull Grupa Bull na świecie 50 krajów

Bardziej szczegółowo

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r. Nie o narzędziach a o rezultatach czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT Władysławowo, 6 października 2011 r. Dlaczego taki temat? Ci którzy wykorzystują technologie informacyjne

Bardziej szczegółowo

Bazy i Systemy Bankowe Sp. z o.o. ul. Kasprzaka 3, 85 321 Bydgoszcz

Bazy i Systemy Bankowe Sp. z o.o. ul. Kasprzaka 3, 85 321 Bydgoszcz Bazy i Systemy Bankowe Sp. z o.o. ul. Kasprzaka 3, 85 321 Bydgoszcz 1 BSB dziś Jesteśmy producentem i integratorem rozwiązań informatycznych 100% udziałów w kapitale zakładowym posiada Narodowy Bank Polski

Bardziej szczegółowo

Wyzwania Biznesu. Co jest ważne dla Ciebie?

Wyzwania Biznesu. Co jest ważne dla Ciebie? Wyzwania Biznesu Zarabianie pieniędzy Oszczędzanie pieniędzy i poprawa wydajności Szybsze wprowadzanie produktów na rynek Maksymalizacja zwrotu z inwestycji portfelowych Trzymać się harmonogramu, budżetu

Bardziej szczegółowo

Projektowanie Infrastruktury Sieciowej v2 2012/09/01

Projektowanie Infrastruktury Sieciowej v2 2012/09/01 Projektowanie Infrastruktury Sieciowej v2 2012/09/01 www.netcontractor.pl Wstęp Era nowych technologii umożliwiła praktycznie nieograniczone możliwości komunikacji niezależenie od miejsca i czasu. Dziś

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

Projekty infrastrukturalne w obszarze obiektów przetwarzania danych. Piotr Trzciński

Projekty infrastrukturalne w obszarze obiektów przetwarzania danych. Piotr Trzciński Projekty infrastrukturalne w obszarze obiektów przetwarzania danych Piotr Trzciński O zespole Zespół 6 osób Odpowiedzialność za: Utrzymanie infrastruktury data centre w Polsce, w tym: Service Management

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 ZARZĄDZANIE SERWISEM IT PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe ZARZĄDZANIE SERWISEM IT Semestr 1 Moduły

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

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

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan testów M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 SPIS TREŚCI 2 Spis treści 1 Historia zmian 3 2 Zakres testów 3 2.1 Integration testing - Testy spójnosci.............. 3 2.2

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

Galileo - encyklopedia internetowa Plan testów

Galileo - encyklopedia internetowa Plan testów Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel..........................................

Bardziej szczegółowo