przypadki użycia – Page 6 – JZ IT Consulting Ltd

Od biznesu do przypadków użycia

Post author:Jaroslaw Zelinski
Post published:28 November 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Wymagania na oprogramowanie są często dokumentowane z pomocą Przypadków Użycia (PU), zwanych w "oryginale" Use Case (UC). Wygodą stosowanie tej konwencji jest traktowanie Systemu jako tak zwanej czarnej skrzynki, czyli czegoś, czego wewnętrznej budowy nie znamy, ale znamy reakcje na bodźce. W przypadku oprogramowania, nie wiemy jak jest ono zbudowane (w momencie zamawiania go, może ono jeszcze nie istnieć), ale wiemy jak reaguje na "polecenia". Jest to uznanie zasady, że zamawiający definiuje CO oprogramowanie ma robić a nie to JAK ono to robi. W przypadku gotowego oprogramowania, lub na etapie poprzedzającym projektowanie, ma to sens, jednak należy pamiętać, że przypadki użycia nie determinują tego co tak na prawdę dostaniemy, co opisałem w artykule o tym co na prawdę opisują przypadki użycia. Generalnie diagram PU jest bardzo dobrym "korzeniem" do analizy i tworzenia pozostałych modeli, ale bez powstającego "natychmiast" modelu dziedziny nie jest możliwe zaprojektowanie granic (bounded context) dla komponentów. Spotykam się w literaturze z tezami, które uważam za słuszne, że jeden system (podsystem) nie powinien przekraczać 50 klas biznesowych w dziedzinie (liczba bliska 100 to ogromny system). Praca nad oprogramowaniem powinna zacząć się od analizy i rozbicia problemu na "strawne" kawałki. Najpierw podział na podsystemy, potem na komponenty, a na końcu konkretne klasy i ich realizacje. Nie ma tu mowy o podziale z perspektywy aktora, bo jeżeli wiemy jaka jest konstrukcja zaprojektowanego młotka albo kalkulatora, to nie możemy ograniczyć (bo nie mamy podstaw) liczby ich użytkowników, bo każdy ma swoje uzasadnione powody by wziąć do ręki np. młotek....

Nowy paradygmat systemowy

Post author:Jaroslaw Zelinski
Post published:26 November 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić? Opisać strategie rynkową firmy, Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów), Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych, Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści, Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi. Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. - SOA) Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.

Modelowanie struktury organizacyjnej

Post author:Jaroslaw Zelinski
Post published:18 November 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Dosyć często spotykam się z modelowaniem struktur organizacyjnych czy nawet ról w procesach, z pomocą diagramów przypadków użycia i hierarchii aktorów z użyciem dziedziczenia. Jest to moim zdaniem kompletne nieporozumienie i fałszywe. Zawiłe diagramy struktur organizacyjnych w postaci aktorów dziedziczących po sobie (nie przytoczę tu żadnego, każdy taki jest w zasadzie zły), na których przełożony dziedziczy po podwładnym (lub podobne konstrukcje), są niemalże zawsze gruntu fałszywe. Studiowanie zakresów obowiązków pracowników firm jawnie pokazuje, że to nie prawda. Z zasady wielu menedżerów działów nie ma kompetencji swoich podwładnych, nie raz szef działu prawnego nie ma, i nie musi mieć, uprawnień radcowskich czy adwokackich, w wielu większych sekretariatach, upoważnienia do pewnych podpisów są przydzielane indywidualnie i szef (szefowa) nie ma tych wszystkich upoważnień. Szef kancelarii tajnej może mieć uprawnienia do informacji tajnej nadane przez ABW, których to uprawnień nie ma nie raz, jego przełożony. Przykładów na fałszywość dziedziczenia uprawnień w strukturze organizacyjnej można podać tak ogromną ilość, że dość częste stosowanie tej konstrukcji wydaje mi się niezrozumiałe. projektują oprogramowanie także, z reguły nieprawdą, jest dziedziczenie praw dostępu. Nie przypadkiem w praktyce stosuje metody macierzowe zarządzania prawami dostępu (niewydolne i nie prawdziwe w sensie biznesowym) lub kontekstowe (dużo lepsze).

Nie każdy współpracujący system to Aktor – czyli jak opisać wymagane interfejsy

Post author:Jaroslaw Zelinski
Post published:9 October 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

To jest to co zrozumie Klient, najprostszy diagram do pokazania, zawiera zakres projektu, granice systemu (najważniejsza rzecz) i aktorów (część różowa tylko dla lepszego zrozumienia treści artykułu). Inny System, jeżeli inicjuje akcję czyli żąda usługi także jest aktorem, ale System realizujący na nasze zlecenie jakieś usługi nie jest aktorem, jest tylko wywoływany, sam z siebie nie inicjuje żadnej akcji. On realizuje jakąś potrzebną nam funkcję. Może się okazać, że Zewnętrzny system ma zarówno interfejs oferowany jak i wymagany, wtedy w projekcie, na diagramie przypadków użycia, warto operować nie nazwą zewnętrznego systemu (np. ERP który może mieć dziesiątki interfejsów oferowanych i wymaganych) a nazwą usługi (interfejs oferowany) lub zdarzenia (interfejs wymagany) będących przedmiotem takich akcji i zakresu projektu. Diagram przypadków użycia to pierwszy test zrozumienia tego co i po co ma powstać. Jest to bardzo prosty diagram i dlatego każde uproszczenie lub niezrozumienie, prowadzi nie raz do poważnych nieporozumień a bywa, że do krachu projektu. To bardzo ważny diagram. Powie nam do czego Systemy Projektowany będzie używany, to cel sponsora. Na tej podstawie można wybrać gotowe oprogramowanie i testując je ocenić przydatność (nie radze wybierać gotowego oprogramowania na bazie prezentacji!). Ale diagram ten nigdy nie powie jaką logikę należy zaimplementować, dlatego w przypadku tworzenia oprogramowania konieczny jest jego projekt: model dziedziny systemu, jako kolejny etap projektu na oprogramowanie dedykowane. Przypomnę także, że przypadki użycia w wersji minimalnej powinny mieć opis: cel jego użycia (co Aktor chce osiągnąć) stan początkowy (wejście, dane wejściowe, itp.) stan końcowy (wyjście, dane wyjściowe itp.) Tu zwracam uwagę, że powyższe to zarazem testy akceptacyjne otrzymanego oprogramowania.

Krótki wpis o śladowaniu

Post author:Jaroslaw Zelinski
Post published:13 June 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Dobrze opracowany, kompletny model organizacji, łączy w sobie: model motywacji biznesowej, [[model struktury organizacyjnej]], model procesów biznesowych (wymieniony już powyżej), model reguł biznesowych. Elementy każdego z tych modeli są ze sobą powiązane: role w procesach są wywodzone ze stanowisk w modelu organizacyjnym, analizowane procesy są wywodzone z modelu motywacji, reguły biznesowe są kojarzone z czynnościami w procesach i wywodzone z aktów prawnych i wewnętrznych zarządzeń. Mając tak opracowany kompletny model organizacji, zawierający śladowanie, i odpowiednie oprogramowanie CASE można przeprowadzić analizę oddziaływania, np. sprawdzić na jakie osoby w organizacji przeniesie się zmiana wybranych reguł biznesowych. Mając model systemu informatycznego skojarzony z procesami, można sprawdzić wpływ awarii poszczególnych podsystemów na procesy biznesowe i ich skutki dla firmy. Takich analiz można wykonać wiele, nie było by to możliwe bez tak skonstruowanego modelu. Dlatego, podstawową wartością poprawnie wykonanych modeli organizacji i użycia właściwych narzędzi, jest nie tylko opracowanie wymagań np. na oprogramowanie. Możliwe jest testowanie reakcji elementów struktury organizacji na zdarzenia np. awarie. Możliwe jest opracowanie projektów integracji, wymiany oprogramowania. Możliwe jest sprawdzenie na co ma wpływ np. nieoczekiwana obecność pracownika. To tylko wybrane przykłady, jednak możliwe jest to wyłącznie pod warunkiem posiadanie poprawnie wykonanego modelu.