Przetwarzanie informacji to tabele te zaś są prozą życia menedżerów :). Podczas wielu projektów związanych z kolekcjonowaniem wymagań na system IT wielokrotnie pojawiał się problem raportów i podobnych działań. Bardzo często wymagania tego typu są specyfikowane za pomocą wzorów raportów. Ma to jednak poważną wadę: zamyka lub utrudnia drogę rozwoju tej funkcjonalności (nie licząc usług płatnego definiowania kolejnych typów raportów świadczonych przez wykonawców systemów). Raporty jednak to tylko wierzchołek góry lodowej, “pod wodą” są dane i ich model czyli sposób zarządzania nimi i ich postać.

Ważną cechą interfejsu użytkownika jest możliwość decydowania o postaci tabel z danymi na ekranie. Nie zawsze uda się łatwo stworzyć nowy raport jednak można w wymaganiach zawrzeć oczekiwanie dowolnego kształtowania tabeli prezentującej wyniki. Niby małe a cieszy. Wybór kolumny do sortowania, filtry i wiele innych. Obiektowe narzędzia coraz częściej zasilane są bibliotekami gotowych rozwiązań, których celem jest między innymi podnoszenie użyteczności interfejsu użytkownika.

Tu okazuje się, że kluczem jest … model danych na etapie definiowania wymagań. Stara zasada: jakie dane taki wynik ich przetwarzania sprawdza się po raz kolejny. Oczywiście nie mam zamiaru udawać tu programisty. Jednak jako analityk współpracującymi z programistami nie raz słyszałem, że model danych to podstawa ich pracy. Przetwarzane informacje to dane biznesowe, nikt poza ich użytkownikiem i analitykiem nie zna ich kontekstu i tylko ta “para” jest w stanie wykonać “dobry” model danych. Elementy aplikacji pracujące na tabelach i same tabele warto więc szczegółowo przeanalizować gdyż ich późniejsza zmiana jest albo bardzo kosztowna albo wręcz niemożliwa w pewnych rygorach czasowych projektów.

Bardzo pomocna jest tu technologia EJB, za Wikipedią:

Enterprise Java Beans (EJB) – technologia będąca jednym z elementów specyfikacji J2EE. Innymi słowy EJB to pewien podzbiór interfejsów J2EE, uważany za jeden z najbardziej zaawansowanych elementów.

Idea EJB opiera się na tworzeniu komponentów, które mogą być osadzane na serwerze (tzw. bean containerze) i wołane zdalnie poprzez protokół RMI over IIOP. Ogólnie wyróżnia się 3 rodzaje komponentów EJB:

• sesyjne EJB (ang. session EJB),
• encyjne EJB (ang. entity EJB),
• sterowane komunikatami EJB (ang. message driven EJB).

Każdy z tych rodzajów komponentów ma różne zastosowanie. Sesyjne EJB są używane do umieszczania w nich logiki aplikacji – czyli kodu, który przetwarza dane. Encyjne EJB reprezentują w sposób obiektowy dane (np. przykrywają relacyjną bazę danych). EJB sterowane komunikatami znajdują zastosowanie w przetwarzaniu asynchronicznym i w zaawansowanych modelach współpracy oprogramowania. Np. model abonent-dostawca: bean rejestruje się jako dostawca pewnej usługi, klienci mogą zarejestrować się jako abonenci.

Główną zaletą EJB jest nakierowanie projektanta na pewne sprawdzone sposoby rozwiązania typowych problemów w systemie rozproszonym: zarządzanie połączeniami, transakcja rozproszona, mapowanie danych na model obiektowy itp. Mimo to użycie niektórych elementów tej technologii wydaje się dość kontrowersyjne. Np. stosowanie encyjnych EJB oznacza rezygnację z przetwarzania danych w modelu relacyjnym. Wszelki dostęp do danych (w tym i masowy) odbywa się poprzez obiekty napisane w języku Java, a zatem niesie ze sobą ograniczenia wydajnościowe i zajętości zasobów. Mimo iż technologia EJB jest popularyzowana przez teoretyków projektowania systemów trudno doszukać się pełnego wykorzystania tej technologii w dużych systemach, w których wydajność odgrywa istotną rolę (zwłaszcza encyjnych EJB).

Źródło: “http://pl.wikipedia.org/wiki/Enterprise_JavaBeans”

EJB to między innymi technologia bezpiecznego manipulowania danymi w systemie. Kłopoty “niedopasowania” pomiędzy obiektowym a relacyjnym modelem danych spędzają sen z powiek niejednemu projektantowi. W prostych systemach można sobie z tym stosunkowo łatwo poradzić stosując proste wzorce obiekt-tabela lub obiekt-wiersz. Jednak przy rozbudowanych systemach te wzorce już się nie sprawdzają. Należy stosować zaawansowane (i bardzo trudne) techniki mapowania obiektowo-relacyjnego (ang. ORM). EJB łączy zarządzanie danymi, reguły biznesowe i udostępnianie ich użytkownikom z możliwością korzystania z serwerów baz danych RDBMS. Jedną z technik jest stosowanie Java Persistence API (zapis danych do bazy oznacza w technologii obiektowej obiekty utrwalane o stereotypie Persistence).

Polecam bliższe zajęcie się tym szczególnie projektantom i analitykom gdyż modele danych to najczulsza cześć projektów systemów, szczególnie biznesowych. Zainteresowanych zapraszam do lektury artykułów Krzysztofa Barteczko Tabele w Java 6, Piotra Kochańskiego JBoss – aplikacje przyjazne użytkownikom, (Software Developer’s Journal, Wrzesień 2007) oraz na stronę JavaSoft.

W tym samym numerze warto przeczytać artykuł Rafała Kędzierskiego Dziesięć największych problemów w projektach informatycznych. Nie będę tu cytował jego obszernych fragmentów, odsyłam do numeru. Warto tu jednak przytoczyć dane opublikowane przez Standish Group w 2004 roku: Najczęstsze przyczyny niepowodzenia projektów informatycznych: 30% – zarzucone, 54% – przekroczony budżet, 66% – brak spełnienia wymagań nabywcy (!), 90% – przekroczony czas.

Co ciekawe poza Java i EJB oczywiście mamy środowisko .NET, Microsoft nie zasypia gruszek w popiele. Podobna tematykę dla tej platformy znajdziecie w artykule Sylwestra Lewandowskiego Enteprice Library 3.1 w następnym numerze. (Software Developer’s Journal, Październik 2007)

MSI Polska:  Jaki jest stopień wykorzystania narzędzi informatycznych w sektorze przemysłowym?

Jarosław Żeliński: Moim zdaniem stopień wykorzystania technologii wspierających przetwarzanie informacji jest w sektorze przemysłowym największy z uwagi na stopień komplikacji większości procesów produkcyjnych. Trudno jest ocenić o ile więcej bo chyba nikt takich badań nie prowadził.  Moim zdaniem każdą firmę można podzielić na podobne obszary jednak ile by ich nie było tylko firmy produkcyjne będą miały obszar produkcji. Firmy handlowe, usługowe, logistyczne niewątpliwie mają skomplikowane procesy biznesowe jednak nie odbiegają one w swej istocie zbytnio od tych w firmach produkcyjnych.  Systemy informacyjne specyficzne dla produkcji są natomiast niszą na rynku właśnie z uwagi na ograniczony rynek na nie (tylko firmy produkcyjne) dlatego dodatkowo są kosztowniejsze.

[MSI]: Czy wartość inwestycji tego sektora w zakresie IT będzie się powiększać?

[JŻ]: Jestem przekonany, że wartość inwestycji w systemy wspomagające procesy produkcji będą rosły. Kluczowym powodem jest narastający trend rynkowy, którym jest produkcja krótko seryjna nie raz  na żądanie pojedynczych zamówień. Narzuca to bardzo restrykcyjne reżimy dla produkcji, których głównymi wymaganiami są obniżanie kosztów, skracanie czasu projektowania i wytwarzania oraz dostarczania produktów. Kolejnym ważnym procesem jest wsparcie odbiorcy po zrealizowaniu dostawy. Wszystko to wymaga obecnie korekty lub nawet zmiany modeli biznesowych oraz narzuca wprowadzanie automatyzacji wszędzie tam gdzie tylko to możliwe. W produkcji automatyzacja praktycznie zawsze związana jest z technologiami informatycznymi stąd postrzegam w tym obszarze duży potencjał wzrostu, moim zdaniem znacznie wyższy niż średnia w branży.

[MSI]:  W jakim kierunku rozwiną się rozwiązania branżowe-dedykowane? Jak jest przyszłość SOA, SaaS, outsourcingu w sektorze przemysłowym?

[JŻ]: SOA, SaaS czy outsourcing to nie technologie i nawet chyba nie architektury. Moim zdaniem to nowe modele biznesowe. Model biznesowy tym się różni od technologii, że opisuje strukturę łańcucha wartości a nie cechy rozwiązań technologicznych. SOA to wewnętrzny model biznesowy jaki opisuje relacje pomiędzy obszarem zarządzania firmą a obszarem dostarczającym zasoby IT, tu sprzęt i oprogramowanie najczęściej dostarcza dział IT. Z perspektywy biznesowej części pracowników organizacji technologie IT stanowią zasoby świadczące konkretne i nazwa usługi. Fakturowanie, księgowanie, raportowanie to funkcjonalności systemów, systemy te zaś to zasoby firmy.  SaaS to nic innego jak nowy model biznesowy dostawców tych technologii. Stają się oni niejako zewnętrznym dostawcą zasobów IT podobnie jak wewnętrzny dział IT. Outsorcing to już powoli proza życia większości firm, które wykonanie czynności nie mających kluczowego znaczenia dla firmy, na różnych zasadach zlecają zewnętrznym, wyspecjalizowanym wykonawcom. Wszystkie te modele to różne odmiany łańcucha wartości, w którym wszystkie wymienione podmioty zajmują różną pozycję jednak są ze sobą powiązane właśnie tym, że każda z tych firm na swoim etapie wnosi wartość do tego łańcucha. Wykorzystana tu technologia moim zdaniem ma drugo- a nawet trzeciorzędne znaczenie.  Rozwiązania dedykowane wpasowują się doskonale w ten model biznesowy gdyż jednym z powodów czyniących z modeli SOA, SaaS i outsourcingu ważne elementy strategii firm jest to, że znacznie obniżają ryzyko ich stosowania, stosowania rzadkich i niszowych rozwiązań a takimi są właśnie rozwiązania branżowe czy dedykowane.

Jarosław Żeliński, Analityk, IT-Consulting.pl

Notatka:

Wywiad ukazał się w: MSI Polska, Raport MSI100: IT w sektorze przemysłowym, Październik 2007: Dostawcy oprogramowania dla sektora przemysłowego w Polsce, http://www.msipolska.pl

Zostałem zaproszony na tę konferencję zarówno jako patron medialny (jako wydawca serwisu IT-Consulting.pl) oraz jako ekspert.

(przedruk: //it-consulting.pl//wp-content/uploads/2018/07/pressnewsdet.aspx?PressNewsId=2440)

Osobą odpowiedzialną za system IT zawsze będzie zamawiający.  Dlatego zamawiający powinien jednoznacznie opisać swoje oczekiwania i zrozumieć potem odpowiedź czyli propozycję ich wykonawcy. Menedżer nie musi uczyć się diagramów UML ale powinien rozumieć modele procesów tak by mieć możliwość ich oceny i zatwierdzania. Dlatego modele procesów powinny być tworzone metodami zrozumiałymi dla menedżerów, moim zdaniem nie jest to notacja UML. Notacja ta jednak jest niewątpliwie doskonałym narzędziem do udokumentowania i przekazania swoich oczekiwań przyszłemu wykonawcy systemu: integratorowi IT. Tak więc wykonaj model procesów biznesowych, określ które procesy chcesz informatyzować. Potem przygotuj na bazie tej analizy listę przypadków użycia przyszłego systemu, uzupełnij ją o model pojęciowy twojego biznesu i firmy i przekaż to do realizacji wykonawcy systemu. Na koniec pozostaje wdrożenie a to już osobny projekt :), socjologiczny.

Mały wstęp dla informatyków

Menadżera interesują procesy biznesowe a nie przypadki użycia. System IT kupujemy po to by te procesy wesprzeć a nie po to by mieć system.

Coraz częściej menedżerowie są jednak obciążani decyzjami  o oczekiwanej funkcjonalności systemów, za które potem płacą.   Paradoksem wielu nieudanych projektów jest to, że dostawcy rozwiązań IT po pierwsze dokumentują sami sobie wymagania, po drugie robią to metodami niejednokrotnie nieznanymi menadżerom (np.. właśnie diagramy UML), ci podpisują dokumenty nie przyznając się, że ich nie zrozumieli (takie strasznie mądre te kwity),  dostawca realizuje projekt a na końcu menadżer mówi: TO NIE TO CHCIAŁEM!

UML czyli jak napisać dokumentację niezrozumiałą dla jej adresata

Systemy często są opisywane od razu za pomocą przypadków użycia,  te zaś opisują zasoby ale już nie relacje między nimi.  Problem,  który przewijał się w większości referatów na konferencji to moim zdaniem mieszanie procesów, zasobów i produktów okraszone wplataniem w to tak zwanych przypadków użycia.  Do tego dochodzi wierność metodom analizy zorientowanym właśnie na przypadki użycia, które to metody są moim zdaniem niekompletne i powodują wiele nieporozumień.  Przypadki użycia to podzbiór pełnej listy działań w firmie. Dlatego bazowanie tylko na nich skutkuje często zupełną utratą kontekstu projektu wdrożeniowego.

Próbą naprawy tego faktu są modele tak zwanych biznesowych i systemowych przypadków użycia, które jednak moim zdaniem zaciemniają tylko obraz. Twierdzenie zaś, że biznes powinien się nauczyć analizy obiektowej skoro zamawia systemy jest moim zdaniem tyle samo warte co twierdzenie, że kierowcy powinni się uczyć termodynamiki silników spalinowych.

Wiec jednak procesy i ich analiza

W analizie procesowej opisujemy organizacje poprzez produkty (głownie dokumenty ale nie tylko) jakie ona wytwarza i procesy wymagane by produkty te powstawały. System IT jako zasób dla procesów jest z natury rzeczy opisywany rolami ludzkimi (aktorzy) i zasobami systemowymi, którymi są programy i sprzęt informatyczny . Procesy to sieć działań. Pojęcie sieci działań i kłopotów związanych z opisywaniem ich za pomocą przypadków użycia wiążą się moim zdaniem z tym, że opis procesowy bazuje na łańcuchach wartości będących łańcuchem następstw przetwarzanych produktów o czym zapominają analitycy programiści a przypadki użycia to lista tych momentów, gdy człowiek korzysta z systemu by proces zrealizować.

Jak więc opisać wymagania na system IT

Kluczowym elementem procesu przejścia od opisu organizacji do opisu systemu IT jest transformacja procesów biznesowych, czyli wewnętrznego łańcucha wartości, na zasoby je wspierające i przypadki ich użycia czyli funkcjonalności systemu.  Kluczowym elementem jest decyzja czy wszystkie procesy i przypadki użycia systemu będą implementowane w systemie czy nie, co nazywa się po prostu analizą rentowności projektu.

Patrząc na procesy biznesowe musimy mieć umiar w szczegółowości ich definiowania, tak by nie doprowadzić do próby algorytmizacji firmy. Pamiętajmy, że musimy zawsze bazować na kompetencjach ludzi i ich wiedzy o tym co i jak mają robić. Jeżeli nie weźmiemy tego pod uwagę to stworzymy system przepływu pracy łączący przypadki użycia w ciągi o skończonej liczbie kombinacji. Pozornie jest to skuteczniejsze jednak kluczową wartością firm jest to, że człowiek radzi sobie z nietypowymi sytuacjami co z kolei powoduje, że nie można mu wiązać rąk scenariuszem. Szczegółowe scenariusze mogą mieć zastosowanie tam, gdzie 100% pracy jest opisana np. w KPA (Kodeks Postępowania Administracyjnego dla Urzędów) ale i tak bałbym się je zbyt szczegółowo opisywać. W firmach rynkowych kluczowym elementem są kompetencje i doświadczenie ludzi i tu typowe systemy przepływu pracy (ang. workflow) stwarzają nie raz wiele kłopotów odzierając  ludzi z prawa użycia ich własnej inwencji.

System dla ludzi

Dlatego wiele gotowych udanych systemów w efekcie ma postać  zbioru usług wspierających zasoby (ludzi) w realizacji ich bieżących prac. Proces to pojęcie w 100% abstrakcyjne nie mające bytów rzeczywistych, jest to abstrakcja łącząca ze sobą pojęcia: produktów, zasobów, reguł, wartości i jakości (dlatego jest tak trudny do zrozumienia jako pojęcie). Próba ich opisu metodami obiektowymi, nie tylko moim zdaniem, jest skazana na niepowodzenie.  Opis procesów często bywa przez niektórych analityków dodatkowo komplikowany przepływem samych danych. Prawdopodobnie jest więc tak, że:

• Procesy są łańcuchami tworzącymi wartość dodaną,
• Procesy są fizycznie realizowane przez zasoby (ludzi, systemy),
• Komunikują się z sobą  zasoby (ludzie, aktorzy) a nie procesy,
• Przepływ danych nie musi być tożsamy z łańcuchem procesów (nawet rzadko taki jest).

Ostatni a uwaga jest jednym z powodów dla których w literaturze można spotkać się z opiniami, że przyczyną fiaska wielu projektów była analiza wymagań bazująca tylko na Diagramach Przepływu Danych (ang. DFD: Data Flow Diagram). Pominięcie modelu procesowego rodzi ryzyko utraty zrozumienia konstrukcji wewnętrznej organizacji.

Model procesów powinien być uproszczeniem, abstrakcją skupiającą się na celowości działań a nie na szczegółach ich realizacji. Te ostatnie mogę podlegać stałym zmianom w firmie. Należy wręcz unikać na etapie zbierania wymagać zbytniego uszczegóławiania opisu. Powinno się zamiast opisowego precyzowania wymagań dla procesu operować przykładami, wzorami produktów każdego procesu. Minimalizuje to możliwość nieporozumień oraz czyni taki opis bardziej jednoznacznym.

Prawdopodobnie więc na etapie opisu wymagań zupełnie wystarczające jest  napisanie, że system powinien wspierać wystawianie faktur i dodać wzór tego dokumentu niż wylistować cechy tego dokumentu takie jak: możliwość wpisania nazwy produktu, liczby sztuk, nazwy jednostki, wartości podatku, automatyczne wyliczanie wartości pośrednich, sum częściowych i summy całkowitej, wypisanie terminu płatności , ?. Wzór dokumentu z jego opisem jest skuteczniejszym i tańszym sposobem specyfikowania wymagań.

(tekst ten to moje przemyślenia po wysłuchaniu referatów na konferencji  UML – zastosowania w biznesie http://www.cpi.com.pl/imprezy/2007/uml/index.php ).

Na podstawie tego tekstu powstał artykuł “Za system IT nie odpowiada informatyk”, który ukazał się w numerze 12.2011 pisma Kadra Kierownicza w administracji. Wszelkie prawa do treści artykułu zastrzeżone.