Wyniki wyszukiwania dla „diagram obiektów” – Strona 20

Model jako symulacja – także w analizie i projektowaniu oprogramowania

Model dziedziny nie powinien więc być diagramem słownikowym (diagram klas z gęsto powiązanymi klasami nafaszerowany dziedziczeniem i asocjacjami). Taki diagram to model pojęciowy (pojęcia słownikowe) nie nadający się do implementacji. Wymaga jeszcze wiele pracy. Jeżeli skażemy na nią programistę, osobę która nie zna tej “dziedziny”, to z dużym prawdopodobieństwem powstanie “coś co nie koniecznie jest tym czymś co powinno powstać”, i nie jest to wina tego programisty tylko tego, który mu dał opis tego co ma powstać w takiej właśnie, niezdefiniowanej postaci. […]
Tak więc szanowni klienci: sprawdzajcie co Wam dają analitycy, jeżeli model dziedziny systemu jest dla Was totalnie nie zrozumiały (to co mówi lub referuje analityk), to prawdopodobnie jest to zły model…

Tak więc model dziedziny opisujący sprzedaż, powinien zawierać obiekt biznesowy Faktura ale obiekt ten nie powinien mieć operacji “nowa faktura”, model powinien zawierać odrębny obiekt np. NarzędzieFakturzysty, mający “w sobie” wiedzę o tym jak się wystawia faktury. Powody są dwa: techniczny opisał powyżej kolega programista, drugi powód jest bardzo prozaiczny: bo faktury same się nigdzie nie wystawiają…

Czytaj dalej

Krótki wpis o śladowaniu

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.

Czytaj dalej

Prawo a wymagania …

Podstawową korzyścią z wyodrębnienia reguł biznesowych i słownika pojęć jest uporządkowanie słownictwa w dokumentacji i uczynienie jej jednoznaczną oraz weryfikacja ewentualnych sprzeczności regulacji wewnętrznych (Zarządzeń, Prawa). Powoływanie się na Reguły biznesowe na modelach procesów biznesowych, pozwala zachować ich prostotę nie tracąc szczegółowości wiedzy o procesach. Tak wykonana dokumentacja procesów nie wymaga częstej i kosztownej aktualizacji, z reguły aktualizowane są procedury i reguły biznesowe, na które modele procesów się powołują.

Tak więc akty prawne to zakazy i nakazy, reguły biznesowe. Oprogramowanie, zależnie od przyjętej konwencji, nie powinno ograniczać ani nawet utrudniać postępowania zgodnego z prawem, może pojawić się oczekiwanie by nie pozwalało łamać prawa. Szczegółowa analiza aktów prawnych, w moich oczach, ma sens gdy projektujemy oprogramowanie. Gdy stawiamy wymagania przed już istniejącym oprogramowaniem, zakładamy że kupimy gotowe, wystarczy wymagać zgodności z prawem w obszarze stosowania oprogramowania. Jeżeli np. oprogramowanie ma pozwalać na wystawianie faktur to znaczy, że powinno być możliwe wystawienie każdej faktury przewidzianej prawem w sposób zgodny z nim. Możemy dodatkowo zażądać by nie było możliwe wystawienie faktury niezgodnej z prawem.

Czytaj dalej

ISA – Interoperability Solution for European Public Administrations

Od czasu do czasu “nawołuję” do formalizowania projektów. Jak nie raz wspominałem, jest to podstawowa metoda uczynienia projektu (jego dokumentacji) przejrzystym. Drugą ważną korzyścią z formalizacji jest tak zwana [[interoperacyjność]], która oznacza możliwość współdziałania technologii różnych dostawców (producentów).

Jak nie trudno się domyśleć, problem dotyczy w szczególności każdej większej organizacji, niejako skazanej na posiadanie rozwiązań z różnych źródeł. Klasycznym przykładem jest administracja publiczna (z interoperacyjnością, a raczej jej brakiem, w Polsce walczymy).

Tak więc polecam osobom związanym z administracja publiczną i instytucjami publicznymi, zapoznanie się z tą inicjatywą. Moim zdaniem bardzo ważna, dobrze że podjęto ten temat gdyż kwestie integracyjne stanowią nie raz istotny koszt projektów IT a bywa, że brak interoperacyjności powoduje wręcz niemożność ich realizacji (np. w Polsce integracja rejestrów Państwowych).

Czytaj dalej

UML MDA czyli od biznesu do projektu logiki systemu

To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania “na papierze”. Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich…). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: “czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da”. W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: “ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów”. W zasadzie taki proces analizy i projektowania jest znany od lat jako [[Model Driven Architecture]] (MDA). […] Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman’a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD (Joint Application Development) to jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.

To jest właśnie problem nazywany “użytkownik nie wie czego chce”. Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman’a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.

Czytaj dalej

Co jest wadą większości analiz biznesowych?

To, że są one tak na prawdę tylko uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji i jej potrzeb (bo nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!

Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek? ( czytaj cały artykuł: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!).

Dlaczego tak jest? Bo oprogramowanie jest tworzone z pomocą języków programowania a te SĄ sformalizowane. Nie da się skompilować do postaci systemu ERP “luźnej prozy”. Napisałem to w Listopadzie 2011, dzisiaj ciąg dalszy. Na początek dodam jeszcze moją konkluzję z pewnej konferencji:

Tak więc język formalny, użyta notacja, czyni projekt wartościowym [jednoznacznym]. Bez tego raczej nie znaczy on po protu nic. (Modelowanie procesów biznesowych – dlaczego mają sens tylko metody formalne i uznane notacje).

Jak to mówią: mocne słowa, ale nie zapominajmy, że mało który projekt biznesowy IT kończy się w terminie i zamyka w założonym budżecie. Zastanówcie jak były dokumentowane Wasze “nieudane” projekty…

Czytaj dalej

Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

Proces biznesowy, nie procedura i nie opis przepływu pracy, to prosty ciąg czynności, których celem jest konkretny rezultat: produkt procesu (jego wyjście).

Proces ma cel, stanowi prosty łańcuch pracy wykonawcy (Rola), radzi sobie z wydarzeniami “utrudniającymi”. Główny ciąg (oczekiwany) zaznaczono szarą strzałką. Pozostałe “atrakcje” to czynności wymuszone pewnymi nie oczekiwanymi (a raczej nie chcianymi), ale przewidzianymi zdarzeniami. Tu nie ma “rombów”, bramek decyzyjnych bo one są cechą “procesów decyzyjnych”, procedur, a te to reguły biznesowe i “wiedza o biznesie” a nie proces biznesowy. Pewne czynności mogą być ograniczone Procedurą, która mówi, że “tylko tak wolno tę pracę wykonać”.

Reguły biznesowe to wewnętrzne (np. zarządzenia) lub zewnętrzne (prawo) ograniczenia. Pojawia się rola czyli wykonawca (tu rola działu HR – opis kompetencji pracowników), on posiada niezbędną wiedzą i umiejętności, potrafi obsługiwać “maszyny” (także oprogramowanie). Tak więc definicja mówiąca, że proces wykonuje się w w środowisku ograniczeń i wymaga zasobów tak właśnie wygląda: zasoby to ludzie (role), ich wiedza i narzędzia pracy, ograniczenia to reguły biznesowe i procedury.

Czytaj dalej

Problem z wzorcem State Machine czyli ile Cię kosztuje workflow

Systemy zarządzania przepływem dokumentów, przepływem pracy lub szumnie nazywane (i na wyrost) sytemami zarządzania procesami biznesowymi, sprawiają wiele problemów. Zaryzykuje tezę, że ich wdrażanie jest ryzykiem nie mniejszym niż wdrażanie systemów CRM (podobno tu odsetek przekroczonych budżetów i terminów przekracza 90%).

Nawet jeżeli ktoś przeprowadzi rzetelną analizę potrzeb i tak dostosuje (zaprojektuje i wytworzy) wdrażany system, że będzie spełniał pierwotne wymagania, okazuje się nie raz, że jego “życie” jest bardzo kosztowne. Problem tkwi w modelu zjawiska jakim jest przepływ pracy. Nie raz wielu z Państwa (mających takie systemy) słyszało po wdrożeniu, że coś wymaga wiele pracy albo jest wręcz nie możliwe już po rozpoczęciu eksploatacji systemu. Albo, że “proces może obsłużyć tylko jeden dokument” i złączenie w jeden kontrolowany bieg wypadków czegoś takiego jak opracowanie oferty w odpowiedzi na przyjęte zapytanie jest niemożliwe albo wymaga “sztucznego połączenia dwóch procesów w jeden” (czyli dwóch dokumentów Zapytanie i Oferta w jeden ciąg). Inny przypadek to “nie da się dowolnie zmieniać statusów dokumentów, proszę określić dokładnie jakie statusy będzie miał dokument oraz kiedy i jak będą się one zmieniały”.

Wiele dokumentów analiz zawiera statyczne tabele dopuszczalnych stanów obiektów implementowane “na żywca” czyli wprost, ich zmiana wymaga pracy programisty. W efekcie system jest bardzo kosztowny w samym posiadaniu i korzystaniu z niego, a jak wiemy środowisko biznesowe jest zmienne. Środowisko dokumentów biznesowych jest szczególnie zmienne.

To są skutki stosowania (często) wzorca State Machine do budowy systemów wspomagający przepływ pracy. Wzorzec ten jest często stosowany w systemach ERP do kontroli pojedynczych dokumentów ale moim zdaniem kompletnie nie nadaje się do implementacji systemów zarządzających przepływem pracy. To nie jest przypadek, że wielu dostawców systemów ERP zaleca jednak integrację z jakimś “dobrym workflow” zamiast bardzo kosztownej kastomizacji (o tym już tu nie raz pisałem).

Co z tym zrobić? Kupujący nie ma możliwości sprawdzenia wnętrza programu (tego jak zostało zaprojektowane) jeżeli kupuje gotowe. Musi bardzo “inteligentnie” stawiać wymagania na oprogramowanie by wychwycić wady jego projektu mogące wywołać lawinę kosztów podczas “zwykłego używania”. Jeżeli zapada decyzja o projekcie dedykowanym warto pokusić się o dobrego analityka i projektanta. A co gdy kupujemy sami i gotowe? Proponuję np. umieszczenie w specyfikacji wymagań zgodności z wzorcem (metamodelem) WfMC a potem sprawdzać czy nas nie oszukano… Ale zwracam uwagę na ryzyko, że nie ma prostej zasady “zawsze taki wzorzec” …

Czytaj dalej