Archive for Styczeń 2011

h1

Status – informacja dla klienta czy dostawcy?

Styczeń 22, 2011

Zanim odpowiem na pytanie postanowione w komentarzu do poprzedniego wpisu, chciałbym przedstawić jeszcze jeden przykład. Przykład będzie dotyczyć statusów zamówienia w systemie składania zamówień przez klienta. Informacja o statusie może być przydatna zarówno dla klienta, który chce być informowany na jakim etapie jest zamówienie, jak i dla dostawcy, który może na tej podstawie tworzyć raporty. Można także pójść dalej i przechowywać dwa rodzaje statusów – zewnętrzne (biznesowe) i wewnętrzne (systemowe). Obydwa statusy mogą wynikać z wymagań.

Zastanówmy się w takim razie w jakich statusach może być zamówienie w analizowanym systemie składania zamówień:

  • zainicjowane/utworzone (z pierwszym dodanym produktem, klient może dodać kolejne produkty lub zaprzestać na jednym);
  • złożone (klient wysłał zamówienie do realizacji);
  • oczekujące na realizację (klient zrealizował płatność na złożone zamówienie lub potwierdził złożenie zamówienia);
  • w trakcie realizacji/realizowane (gdy realizacja zamówienia została rozpoczęta i jest w trakcie, w systemie obsługi opartym o kolejkowanie, można powiedzieć, że zamówienie zostało podjęte);
  • wykonane (przedmiot zamówienia został przekazany do klienta);
  • anulowane (klient wycofał zamówienie z różnych powodów już po złożeniu zamówienia);
  • wstrzymane (realizacja zamówienia została zatrzymana z różnych przyczyn);
  • usunięte (klient usunął zamówienie przed jego złożeniem);

Poniższy diagram (stanów) w UML prezentuje przejścia między poszczególnymi statusami (stanami Zamówienia).

Reklamy
h1

Obsługa wyjątków w wymaganiach

Styczeń 15, 2011

W trakcie funkcjonowania procesów biznesowych, systemów czy aplikacji komputerowych mogą wystąpić sytuacje zwane wyjątkami (ang. exceptions). Mogą one być związane bezpośrednio z czynnościami wykonywanymi przez użytkownika/uczestnika procesu, a także wynikać z problemów z funkcjonowaniem wykorzystywanych narzędzi. W szczególności możemy mówić o:

  • nieautoryzowanych żądaniach,
  • błędnie wprowadzonych danych,
  • niedostępności narzędzi, usług, baz danych,
  • czasie odpowiedzi przekraczającym ustalone parametry biznesowe,
  • awariach wydajności,
  • utracie połączenia
  • itp.

Podczas projektowania aplikacji istotne jest to, aby w wymaganiach wskazać sposób obsługi sytuacji wyjątkowych. Strategie mogą być różne – począwszy od raportowania każdego błędu do użytkownika i przenoszeniem na niego odpowiedzialności poradzenia sobie z sytuacją, poprzez wspieranie użytkownika w rozwiązywaniu problemu, po implementację mechanizmów, które automatycznie próbują rozwiązać zaistniałą sytuację.

Na diagramach przedstawionych (wskazanych) w poprzednim wpisie pojawił się element komunikacji Zarządcy z InterfejsemERP czy pośrednio z BaząProduktów. Patrząc jedynie na ten element można mówić o różnych sytuacjach.

Na powyższym diagramie (diagram sekwencji w UML) zaprezentowano dwa wyjątki: timeout i failure. W przypadku tego pierwszego można by wskazać, że ma powtarzać wywołanie na przykład 3 razy i dopiero przy kolejnej nieudanej próbie informować użytkownika i zapisywać sytuację w bazie. Obsługa wyjątków jest istotna w systemach wykorzystujących usługi lub pracujących na dużych bazach danych. Na diagramie nie wskazano WczesniejZakupione, InniKupowali oraz Promocje, aby zachować pewien poziom ogólności. Jednakże warto przypomnieć, że wskazane elementy uczestniczą w interakcji między WyszukiwarkaProduktow a BazaProduktow. Nie została również pokazana sytuacja, gdy dane pochodzące od użytkownika były błędne.

h1

Czy można pokazać więcej?

Styczeń 11, 2011

Zanim spróbuję odpowiedzieć na pytanie postawione w tytule. Kilka słów komentarza. Przyjęcie pewnych założeń – np. mamy system ERP – powoduje inne spojrzenie na prowadzoną analizę i nie pozwala w pewnych sytuacjach na znalezienie najlepszego rozwiązania, czy może zaprezentowania jak najlepiej efektu, który chcielibyśmy osiągnąć. Może aktualne mechanizmy zastosowane w systemie ERP są niewystarczające, co może być skutkiem ubocznym prowadzonej analizy. Tzw. dostosowywanie się do istniejących narzędzi powoduje, że w jakiś sposób dostosowujemy nasze myślenie, czy docelowy obraz procesów do już znanych mechanizmów. Nie pozwala na spojrzenie szersze, czy nawet wzbudzenie inicjatywy ze strony osób zaangażowanych w projekt. Mało tego czasami zdarza się, że koszty dostosowania się do istniejącego systemu są tak duże, że sam pomysł realizacji usprawnienia czy zmiany przestaje być korzystny albo nie jest wykonalny w akceptowalnym czasie. Zależności między wymaganiami/jakością, czasem realizacji oraz budżetem to już inna kwestia, nad którą nie chciałbym się teraz rozwodzić…

Tymczasem mała dygresja z innego podwórka. W bankowości bardzo często budując strategię sprzedaży staje się przed wyborem: elastyczne procesy i produkty czy standaryzacja produktów. Wydaje się może, że nie jest to kwestia powiązania, ale jak się przyjrzeć bliżej… Opis wymagań abstrahujący od sposobu wykonania, czy ograniczeń na pewnym etapie działania może przynieść w ostateczności bardziej elastyczne rozwiązanie. Stosowanie gotowego rozwiązania i trzymanie się cały czas jego wymagań jest to jakby trzymanie się/powielanie standardów postępowania. Wszystko zależy od tego, co chcemy osiągnąć.

Spójrzmy na poniższy diagram (zamieszczony na stronie it-consulting.pl/blog we wpisie „Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny”):

Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny

 

Diagram powstał jako odpowiedź na mój diagram z wpisu o „Reinżynierii” diagramu klas. Zgadzam się z komentarzem, że mój diagram jest pewnym modelem pojęciowym. Pokazuje jednak pewne zależności między elementami i zatrzymuje się na pewnym etapie ogólności pozwalającym na dyskusję: jakie informacje są potrzebne o produktach? w jaki sposób obsłużyć płatność? czego brakuje? który element jest wykorzystywany przez użytkownika, a co dzieje się automatycznie? Itd. W kolejnych iteracjach mogły zostać dodane kolejne elementy. Zaletą moim zdaniem jest to, że abstrahuje od rozwiązania informatycznego, pokazując pewne informacje logiczne. Wadą jest to, że brakuje wstępnego opisu przypadków użycia, aby przybliżyć dziedzinę. We wpisie o dynamice próbowałem pokazać pewne zachowania, które mogą nastąpić, schodząc na niższy poziom analizy.

Na wcześniejszym diagramie  brakuje mi przestawienia tego w jaki sposób wybierane są produkty i spośród jakich produktów są wybierane. Z doświadczenia wiem, że taka informacja na etapie prezentacji analizy jest cenną informacją. W przypadku nowej aplikacji internetowej pokazuje potencjalny zakres wykorzystywanych źródeł informacji. W przypadku istniejącej aplikacji pokazuje jakie informacje będą potencjalnie wykorzystywane w interakcji z użytkownikiem. Trzymając się zaproponowanego rozwiązania możemy to pokazać jak na poniższym diagramie.

Na diagramie zostały pozostawione operacje tylko z „Zarządcy”. Dodane jednak zostały, trzymając się metody „Role, odpowiedzialność, współpraca”, z zastosowaniem wzorca „Tablica”:

  • tzw. „źródła wiedzy” („Promocje”, „Inni kupowali”, „Wcześniej zakupione”);
  • tzw. „tablica” („Baza produktów”);
  • tzw. „sterownik” („Wyszukiwarka produktów”);

Można by pójść dalej, analizując różne statusy zamówienia i skutki dla systemu, użytkownika. Podobnie można się zastanowić, czy „tablicy” nie zastąpić przez dostawcę usług („interfejs do ERP”).

Podsumowując, myślę, że odpowiedź na pytanie zawarte w tytule jest twierdząca. Stosując zaproponowane metody można pokazać więcej, w szczególności trzymając się pewnego poziomu uogólnienia.

h1

Dynamika – szczegółowość opisu

Styczeń 4, 2011

Trochę zainspirowany komentarzem do jednego z poprzednich wpisów, prowadzącym do artykułu „Diagram klas – czyli „reinżynieria” analizy biznesowej” (z it-consulting.pl/blog), a trochę w wyniku krystalizacji pomysłu na kolejny wpis, postanowiłem spojrzeć na diagram klas z poprzedniego wpisu w sposób bardziej dynamiczny. Jest to o tyle ważne, że sposób prezentacji diagramu klas i wykorzystane konstrukcje wpływają później na sposób implementacji takiego rozwiązania, przedstawiającego w bardziej lub mniej szczegółowy wymagania użytkownika. Chciałbym się skupić na elemencie „Zamówienia” wraz z operacjami wykonywanymi na nim.

Zastanówmy się najpierw czego oczekuje użytkownik systemu do składania zamówień od tego elementu. Odpowiedź nasuwa się sama, chce zaspokoić, w szczególności, dwie swoje potrzeby:

  • potrzebę dodania produktu do zamówienia oraz
  • potrzebę (ewentualnego) usunięcia produktu z zamówienia

Po prostu wyszukuje produkt i dodaje go do zamówienia, bądź wchodzi do „zamówienia” (listy dodanych produktów) i usuwa dany produkt. Świadomie nie wpisałem powyżej zmiany ilości, ponieważ tak naprawdę zwiększenie/zmniejszenie ilości produktu można zinterpretować jako dodanie/usunięcie produktu. Zostańmy jednak przy operacjach dodaj/usuń.

Użytkownik wybiera daną opcję i nie interesuje go co się dzieje wewnątrz systemu. Poniższy diagram w notacji BPMN jest próbą zaprezentowania tego, co mogłoby się dziać.


Diagram obrazuje, że system może kilka różnych czynności wykonać po wybraniu opcji przez użytkownika. Kilka kwestii wymaga jednak komentarza. Na poziomie Klienta zostały przedstawione operacje na najwyższym poziomie tożsame wręcz przyciskom w systemie. Natomiast na poziomie Systemu pojawiają się operacje wskazane na diagramie klas. Użytkownik dodaje produkt do zamówienia, określając jego ilość, a system tworzy pozycję na zamówieniu, dla danego produktu wraz z odpowiednią ilością. Pozycje zamówienia w tym wypadku nie są współdzielone (zastosowano kompozycję).

Można byłoby dalej dodać mechanizmy zabezpieczające przed dodaniem większej ilości produktu niż jest dostępna. Można także określić operacje proklienckie.  Wraz z kolejnymi zamówieniami sytuacja klienta w systemie oraz określonych produktów w pewnym sensie się zmienia. Zwiększając precyzję opisu wymagań można wskazywać kolejne ograniczenia czy też możliwości.

Rozbudowa opisu może przejść od typowej „narracji” (przykład w poprzednim wpisie), przez konkretne „scenariusze” (repezentowane przez tabele, diagramy) po „komunikację” (między elementami, wymianę komunikatami, co częściowo zostało pokazane w niniejszym wpisie).