1 Zaprojektowanie i wykonanie prototypowego systemu obiegu dokumentów (workflow) dla Dziekanatu Wydziału z wykorzystaniem narzędzi open-source i cloud computing. Jarosław Tadeusz Grabowski Maciej Zasada opiekun pracy prof. dr hab. inż. Mieczysław Muraszkiewicz Wydział Elektroniki i Technik Informacyjnych Politechnika Warszawska

2 Podział prezentacji Część 1. Część 2.Wprowadzenie do dziedziny problemu Cel pracy i model procesu Część 2. Opis badań i opis systemu Podsumowanie i kierunki rozwoju

3 Agenda 1. części prezentacjiWprowadzenie Systemy obiegu dokumentów Procesy biznesowe Chmury obliczeniowa Cel pracy Model procesu

4 Wprowadzenie Systemy obiegu dokumentów Źródło: Opracowanie własne

5 Wprowadzenie Procesy biznesoweSekwencje operacji, które przedsiębiorstwo wykonuje w celu osiągnięcia ustalonego celu. Mnogość notacji opisu procedur BPMN; WS-BPEL; jPDL. Pozwalają na interakcję z użytkownikiem poprzez „zadania”. Uruchamiane w ramach silników procesów biznesowych.

6 Wprowadzenie Przykładowy proces biznesowy Źródło: Marcin Sałaciński,„Modelowanie procesów biznesowych”

7 Wprowadzenie Modele dystrybucji chmury obliczeniowejŹródło: Agnieszka Serafinowicz, „Nie błądzić w chmurach”.

8 Wprowadzenie Najczęściej wybierane formy aplikacji dystrybuowanych w modelu SaaS: Narzędzia do zarządzanie treścią; Systemy komunikacji i pracy grupowej. „(…) trendu pozbywania się własnego IT i pudełkowego oprogramowania w firmach nic już nie powstrzyma. Nawet Microsoft, całe lata zarabiający na klasycznym paradygmacie software-on-premise, coraz bardziej zachęca do swoich narzędzi online jak Office365.”

9 Cel pracy Wykonanie projektu i realizacja prototypu systemu obiegu umów cywilno – prawnych, zawieranych w Instytucie Informatyki na Wydziale Elektroniki i Technik Informacyjnych. Umożliwienie integracji zewnętrznych aplikacji z tworzonym systemem. Wykorzystanie technologii opartych na darmowych licencjach. System możliwy do dystrybucji w modelu SaaS chmury obliczeniowej. Porównanie funkcjonalne i wydajnościowe silników procesów biznesowych.

10 Przyjęte założenia – model procesuŹródło: Opracowanie własne

11 Przyjęte założenia – model procesuGłówne elementy wymodelowanego procesu: i …

12 Agenda 2. części prezentacjiWybór silnika procesów Testy funkcjonalne Testy wydajnościowe Architektura systemu Odpowiedzialności komponentów Kierunki rozwoju Podsumowanie

13 Wybór silnika procesówPięć produktów open-source – OpenESB, jBPM, ODE, Orchestra, Drools Flow Komercyjne rozwiązanie referencyjne – Microsoft BizTalk Testy funkcjonalne i wydajnościowe Jak i dlaczego silnik procesów biznesowych został wykorzystany w projektowanej aplikacji. Jak przenosi się sformalizowane obiegi dokumentów w realia procesów biznesowych / zadań użytkowników. Jak dobrano 5 testowanych produktów i rozwiązanie referencyjne. Co obejmują (ogólnie) testy funkcjonalne i wydajnościowe.

14 Wybór silnika – testy funkcjonalnePorównanie oferowanego wsparcia w fazach wytwarzania oprogramowania, m.in. wspierane notacje, zdolność integracji, wdrożenie silnika i definicji procesów Zdecydowana przewaga rozwiązania referencyjnego. Jak podzielono test na kategorie. Co porównywano w ramach poszczególnych kategorii. Jak duża jest przepaść pomiędzy rozwiązaniem referencyjnym, a produktami open-source.

15 Wybór silnika – testy wydajnościoweJakie testy zostały przeprowadzone. W jakich warunkach/środowiskach, jakie ustalono parametry testów. Jak badano rezultaty. Jak zagregowano wyniki widoczne na wykresie. Źródło: Opracowanie własne

16 Architektura rozwiązaniaOpis dekompozycji i komunikacji. Motywacja podjętych decyzji. Na nastepnych slajdach szczegółowo o odpowiedzialnościach. Źródło: Opracowanie własne

17 FluiCore Rdzeń systemu niezależny od specyfiki realizowanego obieguOdpowiedzialności: zarządzanie procesami biznesowymi zarządzanie zadaniami użytkowników zarządzanie użytkownikami generacja plików dokumentów

18 FluiDoc Komponent skupia wszystkie funkcjonalności specyficzne dla realizowanego projektu Odpowiedzialności: realizacja kroków obiegu dokumentów zarządzanie danymi umów świadczenie usług repozytorium wygenerowanych umów

19 FluiUi Bogata aplikacja internetowa (RIA)Interfejs zbudowany z wykorzystaniem GWT i biblioteki SmartGWT Dwuwarstwowa architektura Komunikacja z FluiCore i FluiDoc oparta na usługach sieciowych Część serwerowa udostępnia usługi REST

20 Kierunki rozwoju Adaptacja podpisów cyfrowychIntegracja z istniejącymi repozytoriami dokumentów Całkowita automatyzacja kroków obiegu Wykorzystanie generycznego silnika w innych procesach

21 Podsumowanie Aplikacja zbudowana na bogatej, wydajnej platformie jBPMOparta o model chmury SaaS Wykorzystująca generyczny, udostępniający niezależny od platformy interfejs, silnik obiegu dokumentów

22 Dziękujemy za uwagę.