METODYKA PROWADZENIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW

Transkrypt

1 METODYKA PROWADZENIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW Wszystko to co nas otacza, samo w sobie jest naturalnie proste. Złożone są, nie poszczególne rzeczy, a to, że jest ich wiele i mają na siebie wzajemny wpływ. Celem analizy jest zidentyfikowanie w naszym otoczeniu tych prostych elementarnych rzeczy i zrozumienie ich wzajemnego na siebie wpływu. Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle problemami złośliwymi (Rittel i Webber, 1973). Problem złośliwy to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania. Pamiętajmy, że jedna z najtrudniejszych gier na świecie, mająca miliony możliwych patii szachy to tylko kilkanaście figur i skończony zbiór reguł ich przemieszczania. Nawet największa organizacja to tylko skończona liczba ról i reguł postępowania. Dlatego w moich projektach, których celem zawsze jest poszukiwanie i wdrażanie nowych rozwiązań w organizacjach, stosuję analizę systemową i projektowanie na niej oparte.

2 O AUTORZE Jarosław Żeliński. W 1989 r. ukończył Wydział Elektroniki Wojskowej Akademii Technicznej i do 1991 r. jako adiunkt, prowadził zajęcia z teorii komunikacji i kodowania. Od 1991 r., po opuszczeniu szeregów armii, pracował w branży IT uczestnicząc w projektach z zakresu analiz systemowych, doradztwa organizacyjnego a także wdrożeń systemów IT. W latach , jako kontraktowy menedżer, w czterech spółkach giełdowych zajmował kierownicze stanowiska w obszarze marketingu i zarządzania. Od 1998 roku prowadzi samodzielne studia, publikuje eseje, autorskie prace analityczne i opracowania branżowe w prasie specjalistycznej i gospodarczej oraz w uruchomionym w tym samym roku własnym portalu Od 2004 roku pracuje jako niezależny ekspert i analityk. Niniejszy dokument stanowi w całości opracowanie własne autora zwanego dalej Analitykiem. Wszystkie opisane systemy pojęciowe i notacje są publicznymi standardami (źr. Celem stworzenia tego dokumentu jest zapoznanie Partnerów i Zleceniodawców, a także innych zainteresowanych, z metodyką pracy i produktami pracy Analityka oraz standardami jakich używa. Treść tego opracowania stanowi także opis zakresu szkoleń i warsztatów prowadzonych przez autora tego dokumentu. Wersja: :56:00 Strona 2

3 SPIS TREŚCI O autorze... 2 Analiza biznesowa... 5 Analiza kontekstu Motywacja biznesowa... 5 Wartość dodana... 6 Analiza i formalizacja struktury organizacyjnej... 6 Wartość dodana... 8 Analiza i specyfikacja reguł biznesowych i biznesowego słownika pojęć... 8 Grupowanie reguł biznesowych - Polityki... 9 Wartość dodana Analiza i modelowanie procesów biznesowych Wartość dodana Metoda Wymagania na oprogramowanie Wymagania dziedzinowe system pojęć Struktura dokumentu Wartość dodana Specyfikowanie usług aplikacji i architektury Przypadki użycia jako kontrakt Metoda specyfikowania architektury systemu - model Dziedziny systemu Abstrakcja dziedziny systemu - model BCE Model sekwencji scenariusze opisujące zachowanie systemu Szczegółowy model czyli gdzie i jakie dane Inne produkty analizy i projektowania Wykorzystane standardy i dobre praktyki Literatura Wersja: :56:00 Strona 3

4 ANALIZA BIZNESOWA Wersja: :56:00 Strona 4

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

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

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

8 WARTOŚĆ DODANA Podstawowym celem analizy i normalizowania struktury organizacyjnej jest uporządkowanie systemu podległości i przynależności do komórek organizacyjnych oraz uporządkowanie wiedzy o przydzielonych kompetencjach. Tak uporządkowana struktura jest podstawą do tworzenia modeli procesów biznesowych, które muszą mieć jasno zdefiniowane odpowiedzialności i hierarchię wykonawców procesów. Brak zrozumienia zależności pomiędzy komórkami organizacyjnymi i ich zadaniami, brak uporządkowanego systemu podległości i kompetencji, nie pozwala na poprawne modelowanie ról w procesach biznesowych, co często prowadzi do powstania bardzo wielu zbyt szczegółowych diagramów, na których kompetencje i uprawnienia są modelowane jako ścieżki decyzyjne. Takie podejście jest nieefektywne: powstaje złożona, trudno przyswajalna dokumentacja, wymagająca częstego uaktualniania w takt każdej, nawet najdrobniejszej, zmiany w organizacji. ANALIZA I SPECYFIKACJA REGUŁ BIZNESOWYCH I BIZNESOWEGO SŁOWNIKA POJĘĆ Praktycznie każda organizacja, poza prawem którego musi przestrzegać, ma własne wewnętrzne regulacje. Ich liczba jest zależna od stopnia formalizacji pracy. W przypadkach gdy regulacje te były tworzone latami, bardzo często ich liczba jest większa niż wymaga tego aktualna sytuacja. Bardzo często poszczególne regulacje bywają sprzeczne lub, zamiast reguły, specyfikują jej wariant (np. zamiast określić ogólnie istnienie finansowego progu podejmowania przez kadry kierownicze decyzji o kosztach, specyfikują osobno stanowiska i konkretne kwoty, nie raz niespójne a nawet sprzeczne). Reguły biznesowe mogą być obrazowane na diagramach procesów (diagram w dalszej części). Specyfikowane są w postaci listy zawierającej symbol i nazwę reguły oraz jej formułę w postaci: dla każdego, jeżeli to, zawsze gdy należy itp. Reguły biznesowe, dla zachowania ich jednoznaczności, tworzy się z użyciem pojęć Biznesowego Słownika Pojęć, który jest integralną częścią projektu. W ramach specyfikowania reguł biznesowych mogą się także pojawić kryteria podejmowania decyzji (kryteria decyzyjne). Kryteria decyzyjne są czymś innym niż reguły biznesowe, te drugie ustalają jedynie ogólne zasady. Przykład: regułą biznesową w organizacji będzie zasada mówiąca, że jeżeli pismo jest adresowane imiennie to imię i nazwisko adresata musi być poprzedzane właściwym zwrotem grzecznościowym. Tyle reguła, jaki to ma być zwrot? Właściwy zwrot to decyzja, tę albo podejmuje samodzielnie autor pisma albo tworzymy kryteria decyzyjne (mogą być opisane algorytmem, tablicą decyzyjną, itp.) opisujące to, jaki zwrot należy wybrać. Kryteria decyzyjne są tu dokumentowane z pomocą tak zwanej tablicy decyzyjnej (przykład): Wersja: :56:00 Strona 8

9 Tablica decyzyjna to specjalny, strukturalny zapis zawierający listę warunków, których spełnienie jest kontrolowane, listę możliwych do podjęcia działań, oraz reguły będące konkretnymi kombinacjami spełnionych warunków. Powyżej tablica decyzyjna opisująca regułę wyboru zwrotu grzecznościowego. Narzędzie to pozwala w sposób jednoznaczny, ale także zrozumiały, udokumentować wiedzę jaką jest to, jakie decyzje w jakich warunkach podejmować. Różnica pomiędzy regułą biznesową a kryterium decyzyjnym jest także taka, że powyższa reguła biznesowa będzie obowiązywała w całej, np. międzynarodowej organizacji. Kryterium decyzyjne, mówiące jakiego zwrotu użyć, będzie specyficzne (inne) dla każdego kraju (języka) i będzie to albo wiedza jakiej oczekujemy od pracownika, albo narzucona zasada, zależnie od oceny ryzyka popełnienia błędu i skutków tego błędu (np. obrażony klient zrezygnuje z zamówienia). Inny przykład tablicy decyzyjnej i formy jej budowy, opisujący znane z Kodeksu Drogowego zasady: GRUPOWANIE REGUŁ BIZNESOWYCH - POLITYKI Reguł biznesowych mogą być w dużej firmie nawet setki, dlatego kluczowa jest metoda i sposób zarzadzania nimi. Bazując na pojęciach notacji BMM a także na definicji językowej uznajemy, że: Polityka to «sposób działania osoby lub grupy osób kierujących jakąś instytucją lub organizacją» (źr. Słownik Języka Polskiego PWN, Wersja: :56:00 Strona 9

10 Tym sposobem działania jest właśnie zestaw reguł działania, w przypadku opisu sposobu działania organizacji i firm, są to reguły biznesowe. Innymi słowy reguły biznesowe grupujemy w polityki, będące dziedzinowymi sposobami działania np. Polityka Bezpieczeństwa, Polityka zarządzania kosztami, Polityka obsługi klientów itp. Reguły biznesowe, jako elementy polityki, sterują procesami biznesowymi (opisano w dalszej części). Innymi słowy decyzje podejmowane w toku realizacji procesu biznesowego muszą być zgodne z określoną polityką, muszą więc być stosowane określone reguły biznesowe wszędzie tam gdzie pojawiają się aktywności regulowane daną polityką. Poniżej schemat obrazujący grupowanie reguł w polityki i ich wpływ na procesy biznesowe. WARTOŚĆ DODANA Podstawową korzyścią z posiadania reguł biznesowych i słownika pojęć jest uporządkowanie zasad funkcjonowania organizacji oraz słownictwa w dokumentacji i uczynienie jej jednoznaczną oraz weryfikacja ewentualnych sprzecznych regulacji wewnętrznych (Zarządzeń). Posiadanie udokumentowanych systemów podejmowania decyzji pozwala zapisać wiedzę organizacyjną (know-how) w sposób zrozumiały i łatwy do sprawdzenia. Jeżeli kryteria decyzyjne opisują wszystkie dopuszczalne kombinacje warunków, decyzję taką można zautomatyzować. Powoływanie się na Reguły biznesowe i kryteria decyzyjne na modelach procesów biznesowych, pozwala zachować prostotę diagramów, nie tracąc szczegółowości wiedzy o procesach. Tak wykonana dokumentacja procesów nie wymaga częstej i kosztownej aktualizacji, na bieżąco aktualizowane są procedury i reguły biznesowe, kryteria decyzyjne, na które modele procesów się jedynie powołują. ANALIZA I MODELOWANIE PROCESÓW BIZNESOWYCH Wprowadzanie jakichkolwiek zmian w organizacji zawsze wiąże się z ryzykiem. Skutki planowanych zmian możliwe są do oceny (przewidywania) pod warunkiem posiadania pełnej wiedzy o tym, w jaki sposób organizacja realizuje swoje cele (np. rynkowe). Opisywane jest to w postaci modelu procesów biznesowych. Proces biznesowy, łączy w sobie: Wersja: :56:00 Strona 10

11 Procedury i narzędzia pracy, Role, ich kompetencje i obowiązki, Reguły biznesowe. Proces biznesowy definiujemy jako: Proces biznesowy to aktywność złożona z czynności lub ich łańcucha, przekształcająca stan wejścia procesu w jego stan wyjścia. Proces wymaga określonych zasobów a swoboda jego realizacji może być ograniczona. Zasobami w procesie są wykonawcy czynności, ich umiejętności oraz narzędzia pracy. Ograniczeniami są reguły biznesowe i uprawnienia. Powyższe obrazuje diagram (opracowanie własne autora): Modele procesów biznesowych są obecnie najczęściej wykonywane z pomocą notacji BPMN (diagramy poniżej). Znaczenie symboli notacji jest ograniczone (pragmatyka modelu) do elementów powyższej definicji. Jako pierwsza opracowywana jest mapa kluczowych procesów end-to-end, której celem jest zebranie i weryfikacja wiedzy o podstawowych procesach operacyjnych. Na tym poziomie dokumentowana jest wiedza o tak zwanym wewnętrznym łańcuchu wartości organizacji, który obrazuje sposób wypracowywania wartości np. rynkowej (oferowany produkt lub usługa). Wiedza ta pozyskiwana jest z dokumentów statutowych i podczas wywiadów z zarządem firmy. Model procesów end-to-end to model (o dokładności zależnej od zastanych warunków) kojarzący wejścia i wyjścia procesów opisujących kluczowe działania operacyjne. Specyfikacja taka może wyglądać tak: Wersja: :56:00 Strona 11

12 Powyżej przykład dla firmy handlowo-usługowo-produkcyjnej, ale każda inna firma czy organizacja taka jak urząd czy fundacja jest na tym etapie modelowana na podobnym poziomie abstrakcji w celu zrozumienia i udokumentowania jej wewnętrznej strategii. Powyższy model z reguły ma jeden lub dwa poziomy (proces Inne wymagane przez prawo to ewentualne inne wymagane procesy poza wymienionymi z nazwy nad nim). Procesy end-2-end są następnie dokumentowane (modelowane) jako modele (mapy) z użyciem notacji BPMN: Kolejnym etapem analizy procesów biznesowych jest uszczegółowienie wiedzy o wybranych procesach, poprzez prowadzenie wywiadów, analizę dokumentów operacyjnych, ich statusów, odtworzenie na ich podstawie ścieżek dokumentów oraz przepływu pracy. Na tym poziomie szczegółowości analizowane są: Wersja: :56:00 Strona 12

13 kolejność czynności wykonywanych, reguły biznesowe regulujące przepływ pracy. Stosowanie analizy reguł biznesowych i kojarzenie tych reguł z działaniami, pozwala ująć na diagramach zasady rządzące realizacją procesów. Dzięki temu modele procesów cechują się prostotą graficznej reprezentacji zaś specyfikacja reguł biznesowych i procedur pozwala udokumentować praktycznie całą specyfikę działania firmy i wyeliminować sprzeczne i nakładające się reguły: Czynności w procesach mogą być powiązane z odpowiadającymi im procedurami i regułami biznesowymi. Procedury są standardowo dokumentowane z pomocą list kontrolnych, bardziej złożone mogą być dokumentowane także z pomocą diagramów. Dokumentacja procesów biznesowych zawiera, poza diagramami procesów, specyfikacje reguł biznesowych, procedur oraz wzorów dokumentów. Jest skojarzona ze strukturą organizacyjna za pośrednictwem ról w procesach. Zakres projektu może dotyczyć także konkretnych działań związanych z wprowadzaniem zmian lub realizacją nowej strategii. WARTOŚĆ DODANA Model procesów biznesowych pozwala zweryfikować posiadaną wiedzę o organizacji, przeprowadzić ewentualne optymalizacje procesów, wskazać i zweryfikować zakresy obowiązków dla każdej roli (pracownika), sformalizować działania do tej pory nie uporządkowane oraz zweryfikować ich spójność. Na tym etapie możliwe jest jednoznaczne określenie zakresu projektu wdrażania zmian (w tym nowego systemu IT) oraz, poprzez wskazanie działań wspieranych przez system IT, wyspecyfikowanie wymagań na oprogramowanie, np. ERP a także dedykowane (jeżeli zajdzie taka konieczność). Pominięcie tego etapu bardzo często prowadzi do dużych komplikacji podczas wdrożenia zmian, powodem jest zbyt późne odkrywanie niespójności organizacyjnych. Wersja: :56:00 Strona 13

14 Wersja: :56:00 Strona 14

15 PROJEKTOWANIE ROZWIĄZANIA Wersja: :56:00 Strona 15

16 METODA Autor stosuje zasadę, mówiącą, że w wymaganiem jest projekt. Najpierw słownik języka polskiego: wymaganie «warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać» Tak więc wymagania na rozwiązanie (także na oprogramowanie) to zgodność rozwiązania z jego projektem. WYMAGANIA NA OPROGRAMOWANIE Specyfikowanie wymagań na gotowe oprogramowanie to wskazanie usług, które planowane do wdrożenia oprogramowanie, ma świadczyć użytkownikom. Na tym etapie wskazuje się, które procesy biznesowe mają być wspierane przez nowe oprogramowanie. Usługi oprogramowania wywodzone są z czynności, które chcemy wesprzeć nowym oprogramowaniem. Lista ta powinna być zweryfikowana i spójna: dokonuje się weryfikacji, czy wskazane procesy biznesowe są wspierane przez wyspecyfikowane usługi oprogramowania oraz czy usługi te nie powielają się lub nie ma luk w specyfikacji. Projektem rozwiązania tym czego wymagamy od dostawcy - są schematy blokowe opisujące: usługi (przypadki użycia), ograniczenia oraz model dziedziny (logika biznesowa). Gotowe oprogramowanie to konkretne, istniejące w nim funkcjonalności. Zakup gotowego oprogramowania to kompromis pomiędzy tym co jest dostępne na rynku a potrzebami organizacji (celami zakupu oprogramowania). S pecyfikowanie wymagań na gotowe oprogramowanie powinno być listą kilkunastu, kilkudziesięciu usług a nie detaliczną listą cech, których mogą być setki a nawet tysiące. Gotowe oprogramowanie jest wybierane a nie projektowane. Wyboru dokonujemy na bazie potrzeb (oczekiwanych usług systemu) a nie szczegółowych cech. Nie możliwe jest w rozsądnym czasie i budżecie (rentowność wyboru gotowego oprogramowania) opracowanie dokładnej, detalicznej specyfikacji gotowego, rozbudowanego pakietu oprogramowania. Wymagania dla gotowego produktu przyjmują postać listy usług czyli tego do czego będzie używane, najczęściej w formie tabeli lub listy tak zwanych przypadków użycia. Dokument opisujący wymagane rozwiązanie stanowi najpierw podstawę do wykonania tak zwanej analizy luki (ang. gap/fit analysis), czyli analizy przydatności oferowanego, gotowego oprogramowania polegającej na porównaniu wymagań z możliwościami oferowanego gotowego oprogramowania (tu dostawca opracowuje tak zwane RFI czyli gotowość złożenia oferty). Następnie dostawca opracowuje Koncepcję Wdrożenia czyli specyfikację i wycenę prac wdrożeniowych jakie musi przeprowadzić. Wersja: :56:00 Strona 16

17 WYMAGANIA DZIEDZINOWE SYSTEM POJĘĆ Z uwagi na pewną ogólność (brak szczegółów) listy usług systemu (specyfikujemy jakie procesy ma wspierać system a nie jak ma to robić), ryzyko złego wyboru można znacznie obniżyć, projektując i dodając jako wymaganie, tak zwane elementy dziedzinowe. Są to przykłady struktury kluczowych dokumentów i ich wewnętrzna logika (reguły biznesowe). Co do zasady wymaganiami dziedzinowymi są pojęcia dziedzinowe (ich definicje jako osobny słownik) i reguły biznesowe wraz z ewentualnymi kryteriami decyzyjnymi. Pozwala to uniknąć wielu niejednoznaczności, poprzez uzupełnienie specyfikacji wymagań tym co ma być przetwarzane i jak. Dlatego niektóre projekty wymagają, dla obniżenia ryzyka złego wyboru, dodania do specyfikacji opisu obiektów biznesowych i ich cech oraz powiązanych z nimi zasad przetwarzania. Przykładowe algorytmy operacji: Oferta: Oferowany produkt, operacja wylicz wartość: Wartość = ilość x cena, Brutto = wartość x (1 + VAT), gdzie VAT to liczba (wysokość podatku) w procentach. Jeżeli obiekt Oferta cechuje się tak zwaną stanowością (np. dokument może mieć statusy), powstaje model, który to obrazuje: Pełna dokumentacja zawiera wszystkie istotne obiekty i ich cechy. Elementem tej dokumentacji jest słownik pojęć i specyfikacja reguł biznesowych powstałe na etapie audytu i modelowania procesów. Wersja: :56:00 Strona 17

18 STRUKTURA DOKUMENTU Całość jako Specyfikacja Rozwiązania to dokument, którego struktura opiera się na Przypadkach Użycia aplikacji (Usługi aplikacyjne). Dokument ten łączy w sobie informacje pozyskane na etapie analizy biznesowej (słownik pojęć i reguły biznesowe) i oczekiwania poza-funkcjonalne użytkownika. W przypadku wymagań na gotowe oprogramowanie nie są projektowane mock-up y, model dziedziny, scenariusze przypadków użycia, a słownik pojęć ma zastosowanie ograniczone do zagwarantowania jednoznaczności dokumentacji. Pozostają jednak często wymagania biznesowe. WARTOŚĆ DODANA Szacuje się, że koszty korygowania zakresu projektu w trakcie wdrożenia są nawet 100 krotnie wyższe (zależnie od etapu wdrożenia i jego obszaru) od kosztów takich korekt na etapie analizy biznesowej i projektowania na modelach. Opracowanie dokładnego modelu i jego weryfikacja, a w szczególności kontrola kompletności i spójności wymagań, pozwala na znaczną redukcję tych kosztów. Biorąc pod uwagę, że dobre praktyki wskazują, by projekt był dzielony na etapy mieszczące się w granicach roku budżetowego, tak wykonana analiza pozwala zamknąć taki roczny etap praktycznie bez żadnych zmian w zakresie (nie licząc przyczyn leżących poza projektem, np. zmiany w prawie itp.). Kluczową korzyścią tej części projektu jest zminimalizowanie, ryzyka bardzo kosztownego odkrywania wymagań dopiero w trakcie realizacji projektu. Wersja: :56:00 Strona 18

19 Wersja: :56:00 Strona 19

20 SPECYFIKOWANIE USŁUG APLIKACJI I ARCHITEKTURY Czasami okazuje się, że pewnych wymagań nie realizują dostępne na rynku (w akceptowanej cenie) produkty. Obecnie technologia integracji i gotowe szkielety oprogramowania (tak zwane frameworki) pozwalają na relatywnie szybkie, i bez zbędnych kosztów, opracowanie i wykonanie, brakujących gotowym produktom funkcjonalności, w postaci dedykowanego oprogramowania. Koszt ich wykonania i integracji najczęściej jest znacznie niższy niż koszty ingerencji (tak zwana kastomizacja) w dostarczone gotowe oprogramowanie, nie raz bardzo złożone, które po modyfikacji należy testować i usuwać błędy co rodzi kolejne koszty. Kastomizacja gotowego oprogramowania (wprowadzenie do niego zmian) uniemożliwia przyszłe wykonanie upgrade u oprogramowania bez powtórzenia nakładu pracy i kosztów z okresu wdrożenia. Tak zwana kastomizacja gotowego oprogramowania, czyli modyfikacja jego kodu, to najkosztowniejszy wariant wdrożenia gotowego systemu. Dla systemów dedykowanych poszerza się zakres analizy o projekt systemu, przypadki użycia i ich scenariusze (w tym sekwencje realizowane na obiektach dziedzinowych) oraz makiety ekranów. PRZYPADKI UŻYCIA JAKO KONTRAKT Opis zewnętrznych cech rozwiązania jest standardowo dokumentowany tak zwanym Diagramem Przypadków Użycia (notacja UML). Przypadki użycia to usługi systemu (aplikacji) świadczone aktorowi (użytkownikowi systemu). Przypadek Użycia to usługa Systemu jaką świadczy on jego Aktorowi. Aktorem Systemu nazywamy osobę korzystającą z oprogramowania w celu realizacji określonych zadań. Aktor systemu to odpowiednik Roli w modelu procesu biznesowego. Przypadek użycia oprogramowania to sytuacja, gdy oprogramowanie wspiera Aktora w realizacji konkretnej czynności w procesie biznesowym. Na diagramach Przypadków użycia, wykonanych w notacji UML, aktorem może być także inny zewnętrzny system, inicjujący interakcję z oprogramowaniem projektowanym. Przykład: Wersja: :56:00 Strona 20

21 Przypadki użycia Systemu traktują System jako tak zwaną czarną skrzynkę, opisują to co system ma robić, nie opisują tego jak system ma te usługi realizować. Opis realizacji to etap projektowania systemu. Przypadki użycia, usługi aplikacji są wywodzone (śladowane) wprost z modelu procesów biznesowych jako wymagane usługi aplikacyjne. Każdy przypadek użycia systemu powinien odpowiadać konkretnej aktywności z modelu procesów biznesowych. Możliwa jest sytuacja, gdy jeden przypadek użycia (usługa systemu) wspiera kilka różnych czynności np. usługa zarządzania rejestrem kontrahentów pozwala na wykonanie czynności dodania, usunięcia czy modyfikacji danych kontrahenta, jednak niewłaściwa jest sytuacja, w której jedna czynność wymagałaby od użytkownika użycia kilku różnych usług systemu, gdyż zakłada się, że czynności w procesach na wymaganym do analizy poziomie szczegółowości, to czynności atomowe podobnie jak usługi oprogramowania. W projektach dedykowanych, jednoznaczność opisu danego przypadku użycia nie może budzić wątpliwości, dlatego, poza diagramem przypadków użycia, powinien powstać scenariusz wykonania każdego z nich (dialog aktor - system) w postaci listy lub tabeli. Przykład takiej prostej tabeli pokazano poniżej: Wersja: :56:00 Strona 21

22 Kompletna dokumentacja zawiera opis jak powyżej, dla każdej planowanej usługi systemu. METODA SPECYFIKOWANIA ARCHITEKTURY SYSTEMU - MODEL DZIEDZINY SYSTEMU Model dziedziny systemu opisuje architekturę rozwiązania. Są to obiekty biznesowe reprezentujące treści (opisane wcześniej jako Wymagania dziedzinowe komponent Model wzorca projektowego MVC) oraz obiekty odpowiedzialne za sterowanie zachowaniem oprogramowania. W lżejszej formie można poprzestać na wyspecyfikowaniu reguł i pojęć biznesowych, jednak zaleca się zbudowanie struktury (modelu dziedziny) opisującej obiekty biznesowe i tak zwane usługi czyli automatyzowane umiejętności (algorytmy itp.). ABSTRAKCJA DZIEDZINY SYSTEMU - MODEL BCE Na tym etapie analiza polega na przeanalizowaniu i opracowaniu (zaprojektowaniu) modelu logiki działania oprogramowania, które ma powstać, ale bez ingerowania w architekturę jego implementacji, który opracuje developer. Na tym etapie planowane rozwiązanie (projekt) jest rozkładane na trzy logiczne elementy (klasy na diagramie klas UML): Wersja: :56:00 Strona 22

23 Model na tym poziomie ogólności (metamodel dziedziny) pokazuje ich zależności i wzajemną odpowiedzialność (poniżej uproszczony przykład): Na tym poziomie nie używamy atrybutów a jedynie operacje (i metody), ewentualnymi parametrami żądań są inne obiekty (tak zwane modelowanie zorientowane na interfejsy). Wersja: :56:00 Strona 23

24 Kolejnym etapem szczegółowego opisania wewnętrznej architektury może być wzorzec DDD (Domain Driven Design) operujący pojęciami: entity, agregate, factory, service, repository, value object (ten wzorzec opisuje dokładnie E.Evans, patrz literatura). Wybór poziomu abstrakcji modelowania dziedziny (wybór wzorca BCE lub DDD) zależy od warunków projektu, ryzyka i ewentualnej umowy z developerem. MODEL SEKWENCJI SCENARIUSZE OPISUJĄCE ZACHOWANIE SYSTEMU Kolejnym poziomem analizy i projektowania jest opracowanie tak zwanego modelu sekwencji dla wybranych, nietrywialnych przypadków użycia (usług systemu). Pokazuje on proces realizacji każdej usługi wewnątrz oprogramowania przez obiekty modelu dziedziny w następujący sposób: Powyższy diagram stanowi informację o tym jak dany przypadek użycia (funkcjonalność systemu) ma być realizowany przez obiekty modelu dziedziny systemu (czyli jego wewnętrzne składniki). Opis ten dokumentuje logikę biznesową realizowaną w systemie. Zabezpiecza to Zamawiającego przed ryzykiem nieporozumień (niezrozumienia) z Wykonawcą w kwestii szczegółów algorytmów i reguł biznesowych. Diagram sekwencji, zależnie od poziomu abstrakcji, modeluje komunikacje pomiędzy obiektami biznesowymi lub komponentami. Użycie wybranych scenariuszy jako testów, pozwala także sprawdzić czy developer prawidłowo, zgodnie z projektem, wykonał oprogramowanie. SZCZEGÓŁOWY MODEL CZYLI GDZIE I JAKIE DANE Klasy Entity (obiekty) modelu dziedziny, są odpowiedzialne za przechowywanie informacji. Jeżeli projekt (zakres projektu) tego wymaga, tworzone są szczegółowe modele opisujące realizację klas Entity. Są to diagramy klas UML w postaci jak poniżej: Wersja: :56:00 Strona 24

25 Entity może reprezentować np. abstrakcyjna Fakturę VAT, realizacja tej klasy to agregat reprezentujący strukturę jaka przechowuje informacje tego dokumentu. Klasy te mają operacje udostępniające te informacje w określonej postaci (pełna lub okrojona). W przyjętej tu konwencji atrybuty są definiowane w Dziedzinowym Słowniku Pojęć (dokładnie opisuje definicje pojęć użytych np. jako atrybuty lub etykiety) wspólnym dla całego modelu dziedziny. Konkretne typy danych określa już developer. Na etapie analizy mogą pojawić się rekomendacje do tworzenia tak zwanych typów złożonych (ValueObject). Wersja: :56:00 Strona 25

26 INNE PRODUKTY ANALIZY I PROJEKTOWANIA Zależnie od złożoności projektu i jego ryzyka, a także potrzeb, mogą powstać dodatkowe elementy dokumentacji. W szczególności mogą to być projekty ekranów (interfejs użytkownika, tak zwane mockup y) oraz testy odbiorowe użytkownika (User Acceptance Tests). Dla złożonych scenariuszy przypadków użycia mogą pojawić się modele sterowania interakcję opisujące kolejność ekranów, opcjonalnych scenariuszy itp. Możliwe jest uzgodnienie z dostawcą oprogramowania (developerem) inne, bardziej szczegółowe lub w innej konwencji, projektowanie logiki dedykowanego oprogramowania. Lista stosowanych standardów i dobrych praktyk w dalszej części. Wersja: :56:00 Strona 26

27 WYKORZYSTANE STANDARDY I DOBRE PRAKTYKI Standardy, dobre praktyki i zalecenia wykorzystane w Metodyce: 1. Metodyka prowadzenia projektu analizy biznesowej i specyfikowania wymagań: BABoK, International Institute of Business Analysis ( 2. Metodyka analizy i optymalizacji procesów biznesowych organizacji: Rummler-Brache Group ( 3. Teoria łańcucha wartości rynkowej, metody analizy i modelowania przewagi konkurencyjnej: M.E.Porter ( 4. Języki modelowania, sformalizowane systemy pojęciowe obszaru inżynierii oprogramowania: Object Management Group ( w szczególności notacje UML, BPMN, BMM. 5. Języki modelowania, sformalizowane systemy pojęciowe obszaru strategii i zarządzania: Business Rules Group ( system budowy reguł biznesowych, notacja BMM (Business Motivation Model). 6. Wzorce projektowe i dobre praktyki obszaru modelowania logiki biznesowej metodami obiektowymi: Domain Driven Design Community ( Standaryzacja metod integracji modelowania biznesowego w tym modele motywacji, procesów biznesowych, reguł biznesowych, systemów pojęciowych: Business Process Management Initiative ( 8. Forum autorytetów metod analizy zorientowanych na procesy, Business Process Manifesto ( LITERATURA (wybrane pozycje, wytłuszczenie książki mające szczególny wpływ na opisaną metodykę): 1. Tytuł: Metody obiektowe w teorii i praktyce, Autor: Ian Graham, Wydanie: WTN, Warszawa Tytuł: Inżynieria Projektowania Strategii Przedsiębiorstwa, Autor: Lechosław Berliński, Ilona Penc- Pietrzak, Wydanie: Difin, Warszawa Tytuł: Inżynieria systemów informacyjnych, Autor: Paul Beynon-Davis, Wydanie: Warszawa, WNT Tytuł: UML. Inżynieria oprogramowania. Wydanie II, Autor: Perdita Stevens, Wydanie: Helion Tytuł: Strategie Konkurencji, Autor: David Faulkner, Cliff Bowman, Wydanie: Gebethner i ska, Warszawa Tytuł: Cybernetyka w zarządzaniu. Modelowanie cybernetyczne. Sterowanie systemami, Autor: Zdzisław Gomółka, Wydanie: Warszawa, Placet Tytuł: Modele referencyjne w zarządzaniu procesami biznesu, Autor: Tadeusz Kasprzak, Wydanie: Difin, Warszawa Tytuł: Teoria i Inżynieria Systemów, Autor: Czesław Cempel, Wydanie: Czesław CEMPEL, Poznań Tytuł: Business Inteligence, Autor: Jerzy Surma, Wydanie: PWN, Warszawa Tytuł: Architektura systemów zarządzania przedsiębiorstwem. Wzorce projektowe, Autor: Martin Fowler, Wydanie: Helion Gliwice Wersja: :56:00 Strona 27

28 11. Tytuł: Head First Object-Oriented Analysis and Design, Autor: Brett D. McLaughlin, Gary Pollice, David West, Wydanie: Helion, Gliwice Tytuł: Projektowanie hurtowni danych. Zarządzanie kontaktami z klientami (CRM), Autor: Todman Chris, Wydanie: WNT, Warszawa Tytuł: Komponenty w UML, Autor: John Cheesman, John Daniels, Wydanie: WNT, Warszawa Tytuł: UML przewodnik użytkownika, Autor: Grady Booch, James Rumbaugh, Ivar Jacobson, Wydanie: WNT, Warszawa Tytuł: Inżynieria oprogramowania, Autor: Ian Sommerville, Wydanie: WNT, Warszawa 16. Tytuł: Projektowanie zorientowane obiektowo. Wzorce projektowe, Autor: Alan Shalloway, James R. Trott, Wydanie: Gliwice, Helion Tytuł: Wdrażanie strategii dla przewagi konkurencyjnej, Autor: Robert S. Kaplan, David P. Norton, Wydanie: PWN, Warszawa Tytuł: Wzorce projektowe, Autor: E.Gamma, R.Helm, R.Jonson, J.Vlissides, Wydanie: Helion, Gliwice Tytuł: UML w kropelce wersja 2.0, Autor: Fowler Martin, Wydanie: LTP 20. Tytuł: Analysis Patterns. Reusable Object Models, Autor: Martin Fowler, Wydanie: Addison- Wesley, Tytuł: Podstawy metod obiektowych, Autor: James Martin, James J.Odell, Wydanie: WNT, Warszawa Tytuł: Tworzenie architektury oprogramowania, Autor: Christine Hofmeister, Robert Nord, Dilip Soni, Wydanie: WNT, Warszawa Tytuł: Business Process Management, Autor: John Jeston, Johan Nelis, Wydanie: Butterworth- Heinemann, 2008 (Reprint 2009) 24. Tytuł: Requirements Analysis and System Design, Autor: Leszek A. Maciaszek, Wydanie: Addison Wesley Tytuł: Object-Oriented Construction Handbook, Autor: Heinz Zullighoven, Wydanie: Elsevier Inc Tytuł: Stosowanie przypadków użycia, Autor: Geri Schneider, Jason P. Winters, Wydanie: WNT, Warszawa Tytuł: Porter o konkurencji, Autor: Michael E. Porter, Wydanie: PWE, Warszawa Tytuł: Strategie Konkurencji, Autor: Michael E. Porter, Wydanie: MT Biznes, Warszawa Tytuł: Michael E. Porter, Autor: Przewaga konkurencyjna, Wydanie: Helion, Gliwice Tytuł: Systems Analysis and Design with UML Version 2.0, Autor: Alan Dennis, Barbara Halley Wixom, David Tegarden, Wydanie: Second edition, John Wiley and Sons, Inc. 2005, USA 31. Tytuł: UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji, Autor: Craig Larman, Wydanie: Helion, Gliwice Tytuł: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach, Autor: Heinz Züllighoven, Wydanie: Morgan Kaufmann; 1 edition, October 13, Tytuł: Domain-Driven Design: Tackling Complexity in the Heart of Software, Autor: Eric Evans, Wydanie: Addison-Wesley Wersja: :56:00 Strona 28