o modelowaniu procesów i systemów 

Z racji tego, że publikacja odnośnie zwinnego podejścia w zakresie modelowania procesów biznesowych (WMB) ?pisałem o tym kilka dni temu w tekście pt ?Krajowa Konferencja Inżynierii Oprogramowania?- ukazała się w limitowanej edycji 150 egzemplarzy pozwalam sobie na publikację skanu tego tekstu.

Ostatni czwartek i piątek spędziłem wspomagając bardzo ciekawą firmę. Otóż jest to Polska firma pisząca systemy wspierające szerokorozumianą e-administrację. Nasuwa sie pytanie a gdzie są te systemy? Otóż w USA. Tak tak Polskie, niewielkie, firmy mogą pisać oprogramowanie wspierające obywateli innych Państw. A my, obywatele 4,5,6 RP jesteśmy gorsi? Myślę, że nie ale za to bardziej specyficzni bo u nas znów ogłoszony zostanie przetarg, do którego będą mogły przystąpić (czyt. będą spełniać warunki formalne) 3-4 firmy, potem lista odwołań, i? kolejny przetarg? ach szkoda pisać. Nawiasem mówiąc to kolejna średniej wielkości firma w Polsce, z którą miałem okazję współpracować, która robi rzeczy wielkie. Szkoda, że są one niedoceniane na rynku lokalnym bo mało jest firm, które mają doświadczenie zdobyty w kilkunastu zagranicznych projektach.

Na koniec pragnę tylko pochwalić się, że jako konsultant otrzymałem dobre i bardzo dobre noty. Dziękuję.

W tym miejscu pozwolę sobie zebrać kilka cech, które świadczą o tym, że mamy do czynienia z dobrym modelem biznesowych przypadków użycia. Oto one:

• Biznesowe przypadki użycia są zrównane ze strategią firmy ? wspierają cele organizacji.
• Przypadki użycia są zgodne z organizacją, którą opisują.
• Wszystkie przypadki użycia są znalezione. Po zebraniu, przypadki użycia wykonują wszystkie zadania w ramach organizacji.
• Każde zadanie w ramach organizacji jest ujęte w przynajmniej jednym Przypadku Użycia.
• Istnieje równowaga między liczbą przypadków użycia a ich wielkością:
• Model zawiera kilka przypadków użycia  – przez co jest łatwiejszy do zrozumienia.
• Przypadek użycia opisuje pełen przepływ informacji, który produkuje coś wartościowego dla klienta.
• Każdy przypadek użycia jest unikatowy. Jeżeli przepływ informacji jest taki sam lub podobne do innego przypadku użycia, trudno będzie utrzymać je później w zsynchronizowaniu. Należy uwzględnić scalenie je w pojedynczy przypadek użycia.

Ile z podanych cech spełniają Twoje modele?

Kilka tygodniu temu (http://www.wolski.waw.pl/2009/07/kkio-2009/) zapowiedziałem swój udział na Krajowej Inżynierii Oprogramowania. Tak tez się stało. 15 września w trakcie sesji pt: ?Modelowanie systemów? miałem okazję zaprezentować zarys metodyki WMB ( http://www.wolski.waw.pl/wmb/).

Moje wystąpienie na temat ?Zwinnego modelowania wymagań biznesowych w wytwarzaniu oprogramowania? spotkało się się z życzliwym przyjęciem uczestników  XI Krajowej Konferencji Inżynierii Oprogramowania, które zaowocowało żywą dyskusją.

Na koniec dodam, że moje wystąpienie było afiliowane i wykonane na rzecz firmy, w której jestem konsultantem, co uczyniło ją jedną z nielicznych firm komercyjnych, które poddały swoje nowatorskie rozwiązania z zakresu inżynierii oprogramowania ocenie niezależnych ekspertów z tej dziedziny.

Publikacja, która ukazała się jako rozdział w książce (okładka poniżej),  świadczy o pozytywnej recenzji i akceptacji drogi rozwoju jaka została obrana w obszarze zwinnego modelowania.

Budowanie modeli biznesowych coraz częściej znajduje uznanie wśród projektantów systemów. Wiąże się to z faktem, że modele biznesowe stanowią podstawę całego przedsięwzięcia bowiem pozostałe dyscypliny inżynierii oprogramowania (bazując teraz na dyscyplinach RUP )czerpią z niej w następujący sposób:

• Dyscyplina Wymagania wykorzystuje biznesowe modele jako istotne dane wejściowe dla zrozumienia wymagań systemu.
• Dyscyplina Analiza i Projekt wykorzystuje biznesowe modele jako dane wejściowe dla określenia systemów oprogramowania, które płynnie pasują do organizacji.
• Dyscyplina Wdrożenia wykorzystuje biznesowe modele jako pomoc w planowaniu zastosowaniu systemu oprogramowania.

Co więcej modelowanie biznesu jest procesem iteracyjnym, który zaczynając kawałek po kawałku, w każdej iteracji, pozwala nam na na lepsze poznanie organizacji a tym samym dostarczenia istotnych treści dla procesu wytwórczego oprogramowania.

Celem modelowania biznesu jest:

• Zrozumienie bieżących problemów w docelowej organizacji i określenie potencjałów udoskonalenia.
• cena wpływu zmiany organizacyjnej.
• Zapewnienie, że klienci, użytkownicy, inwestorzy oraz inne strony będą rozumieć organizację w ten sam sposób.
• Wyprowadzenie wymagań systemu oprogramowania, które jest konieczne, aby wspierać docelową organizację.
• Zrozumienie jak system oprogramowania, który ma być wykorzystywany w przyszłości, wpasuje się w organizację.

Schemat organizacyjny nie jest wystarczający, aby zrozumieć działanie firmy. Potrzebujemy również dynamicznego widoku przedsiębiorstwa. Model biznesowy zapewnia statyczny widok konstrukcji organizacji i dynamiczny widok procesów w obrębie organizacji.

Dla mnie to bardzo ważne  gdyż tylko dzięki widokom z różnych perspektyw (statycznej i dynamicznej) jestem wstanie poprawnie zaprezentować na modelu jak nowy system będzie wspierał organizację.

User story to opis celów zorientowanych na użytkownika, jakie jedna lub więcej osób osiągnie za pomocą Twojego produktu. User stories używa się do osiągnięcia celu zawsze wtedy, kiedy jest osoba obsługująca interfejs . User story pisze się w formacie

Jako [osoba odgrywająca daną rolę] chcę [wykonać jakąś czynność] aby [osiągnąć jakiś cel].

W ten sam sposób można pisać scenariusze przypadków użycia, przy których należy uwzględnić, że scenariusz może obejmować kilka user story. Takie podejście pozwala także na zastosowanie modelowania w języku UML w SCRUM i tym samym wpisuje sie w nurt agile modeling ? zwinnego modelowania.

Kilka porad odnośnie przypadków użycia i aktorów.

Przypadek użycia nie dostarcza funkcjonalności aktorowi

Problem: Często oznacza to, że każdy przypadek użycia sam w sobie nie dostarcza wartości aktorowi.

Rada: Proszę połączyć fragmentaryczne przypadki użycia w kompletną sekwencję takich fragmentów, które łącznie zapewnią wartość aktorom.

Stanowiska pracy jako aktorzy

Problem: Powszechnym błędem jest tworzenie aktorów, którzy odzwierciedlają stanowiska pracy organizacji. Tworząc aktorów, którzy odzwierciedlają stanowiska pracy przypadki użycia będą kształtowane, aby wspomagać stanowiska pracy a nie pracę, którą mają wykonać jednostki.

Rada: Jeżeli aktorzy odzwierciedlają stanowiska pracy, proszę zmodyfikować aktorów, aby dostosować ich do czynności, które mają wykonać w pracy.

Urządzenia jako aktorzy

Problem: Proste urządzenia, takie jak skanery i drukarki nie pomagają zbytnio w identyfikacji przynoszących wartość przypadków użycia. Aktorzy, których należy szukać, są to ludzie oraz inne systemy, które współdziałają z systemem.

Rada: Jeżeli aktorów określono dla urządzeń, trzeba odszukać osobę, która "stoi za" urządzeniem i zasugerować ją jako aktora.