analiza biznesowa

Read more about the article Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostatnio wzorzec DDD jako narzędzie dokumentowania analizy. Faktycznie, czytelnicy mają wiele racji, jest on dość "bliski implementacji". Niejednokrotnie "lepszym pomysłem" jest opis logiki systemu na nieco wyższym poziomie abstrakcji pozostawiając tym samym więcej swobody developerowi. [...] Nieco inne podejście, to które stosuję obecnie, opisuję poniżej. Zachowując podstawowe znaczenia tych trzech klas, dostosowałem je do wzorca MVVC. Jest to o tyle wygodne i ważne, że stosowanie wzorca BCE wyłącznie do modelowania logiki biznesowej wymaga zachowania hermetyzacji komponentu Model. W takim układzie boundary nie będzie elementem komponentu View a Modelu. Jego rola to stworzenie dedykowanego interfejsu do model np. pomiędzy komponentem View lub Controlerem. Dzięki temu możliwe jest stworzenie odrębnego interfejsu dla View na duży ekran i odrębnego dla View na np. małych ekranach smartfonów. Tak więc jest moim zdaniem droga do modelowania wymagań metodą "tak to ma działać" a nie tylko "tak to ma wyglądać", bo to drugie jest przyczyną wielu problemów...

Czytaj dalejWzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Kim więc jest dobry analityk?

Skoro logikę biznesową "programuje się" (implementuje się) z użyciem obiektowych wzorców projektowych, to ideałem było by wskazać te wzorce, które wg. najlepszych praktyk są wykorzystywane do implementacji logiki biznesowej i uczynić z nich "klocki", na które należy, na etapie analizy biznesowej, rozłożyć problem. To się np. nazywa DDD czyli siedem wzorców spośród wielu.Korzyści są ogromne, bo "wycinamy" etap głuchego telefonu między Zamawiającym i wymaganiami w postaci prozy i tabel a developerem, który ma zrobić obiektowy model czegoś czego tak na prawdę nie rozumie, a opis prozą jest niestety bardzo niejednoznaczny i podatny na przekłamania (głuchy telefon).

Czytaj dalejKim więc jest dobry analityk?
Read more about the article Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Kim więc jest dobry analityk?Jest to projektant, który potrafi analizowaną organizację "rozłożyć na elementy składowe". Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie "rysunek". Jest modelem w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję i zasady wzajemnego łączenia.Analiza Biznesowa to rozłożenie analizowanego "przedmiotu" na skończony zestaw elementów, który z określoną dokładnością zachowuje się jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania.Poziomy szczegółowości wymagań to:cele biznesowe (produkty procesów biznesowych) opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania) opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)

Czytaj dalejPoziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa
Read more about the article Projekt wykonany – co było robione

Projekt wykonany – co było robione

Powyższe jest zgodne z zaleceniami OMG.org (https://www.omg.org/mda), audyt to etap CIM a projektowanie przypadków użyci i modelu dziedziny to etap PIM.Wykonanie takiej analizy jest pracochłonne i wymaga dużego doświadczenia, umiejętności analiz procesów biznesowych, projektowania obiektowego i dobrego narzędzia CASE, jednak modele te pozwalają także przeprowadzić analizy wpływu (zależności pomiędzy procesami, skutki i podatność na awarie oprogramowania itp.) oraz zredukować do minimum prawdopodobieństwo przekroczenia terminu i kosztów (statystyki wskazują na średnie przekroczenie kosztów o 60% i terminów o 200% projektów z niskiej jakości specyfikacji wymagań). Praktyka autora wskazuje, że warto taką analizę przeprowadzić dla projektów, których budżet przekracza 50-70 tys, zł i większych.

Czytaj dalejProjekt wykonany – co było robione
Dom bez planów

Proces zbierania i analizy wymagań u developera

Analiza Biznesowa i specyfikacja wymagań opracowana metodą opisywaną tu i na stronach OMG, jest od tej ostatniej (grupa konsultantów i sesje warsztatowe) znacznie tańsza. W czasie trwa podobnie, jednak robi to z reguły jedna osoba (tak! ale przy założeniu ma stosuje zaawansowane narzędzia CASE nie tylko do tworzenia diagramów ale także do ich weryfikacji śladowania zarządzania spójnością modeli itp.), a efektem jest projekt logiczny a nie dopiero lista wymaganych cech. Korzyść jest więc podwójna. Jeżeli zrobi to Analityk wynajęty przez Klienta a nie Dostawcy, to wszelkie prawa (know-how) do projektu pozostają po stronie nabywcy.Można powiedzieć, że to trudne i kosztowne. Trudne owszem, wymaga doświadczenia i wiedzy zarówno z zakresu zarządzania jak i inżynierii oprogramowania. Per saldo, wliczając w to koszty modyfikacji na etapie wdrażania i odkrywania wymagań (wady specyfikacji nie poddającej się weryfikacji) jest to proces zawsze tańszy (badania kierowników projektów wskazują, że zła jakość wymagań generuje dodatkowe koszty rzędu 60% wartości projektu, koszt takiej analizy nie przekracza zaś 20%). Do tego pojawiają się potencjalne koszty nieujawnione klientowi: prawa autorskie do projektu i aplikacji. Jeżeli firma będąca wykonawca oprogramowania robi analizę swojego klienta i potem mu sprzedaje prawa do jej wyników wraz z dostarczanym oprogramowaniem, to jest to klasyczny przypadek anegdoty o konsultantach, którzy zapytani o to która jest godzina, proszą Cie o Twój zegarek, odpowiadają na pytanie która godzina i wystawiają fakturę za usługę i także za zwracany Ci Twój zegarek.

Czytaj dalejProces zbierania i analizy wymagań u developera
Read more about the article Wymagania biznesowe a wymagania wobec produktu – rola analityka

Wymagania biznesowe a wymagania wobec produktu – rola analityka

I tak mamy: 100% interfejsu użytkownika zamawia użytkownik (sam lub z pomocą specjalistów), 100% wymagań funkcjonalnych realizuje Model Dziedziny (projekt analityka-projektanta), 100% wymagań poza-funkcjonalnych realizuje developer (projekt i implementacja). Developer także implementuje model dziedziny z pomocą technologii jakiej używa.A jeżeli klient powie: nie mamy tych wzorów dokumentów i ekranów! To pierwszy sygnał, że nie ma podstaw do zamawiania jakiegokolwiek oprogramowania, bo najpierw trzeba "wiedzieć co się chce".Jak to zrobić? Tu kłania się analiza biznesowa: modelujemy procesy biznesowe, dla każdego z nich ustalamy wejście oraz efekt (produkt) czyli właśnie owe "wzory dokumentów". Po uporządkowaniu tego i upewnieniu się, że nie ma w tym bałaganu (powtórki, braki, niekonsekwencje, sprzeczności itp.) możemy pytać o gotowe oprogramowanie lub "zamawiać" jego wytworzenie. Produktem pracy analityka powinny być, poza modelami procesów bo one są narzędziem a nie celem, obiektowy model dziedziny czyli model tego jakimi informacjami i jak zorganizowanymi operuje organizacja, oraz to jak pracownicy tej organizacji chcą się komunikować z oprogramowaniem (źrodłem informacji jest jednak klient).Mamy czysty podział odpowiedzialności i łatwość rozliczenia projektu. Na czym polega haczyk? Klient nie może unikać odpowiedzialności za skutki swoich decyzji i udzielanych informacji. Ale też, co jest kluczowe: Analityk musi zrozumieć problem i zaproponować rozwiązanie.Jednak nie jest rolą analityka wykonanie oprogramowania! To "jak - technologia - ma to zostać zrealizowane" jest decyzją developera. Ma dużo pracy. Nie zapominajmy, że kod realizujący tak zwaną logikę biznesową to ledwie kilka procent całości kodu aplikacji, jednak nie zapominajmy także (programiści), że zła logika biznesowa dyskwalifikuje całe to oprogramowanie z prostego powodu: staje się nieprzydatne.

Czytaj dalejWymagania biznesowe a wymagania wobec produktu – rola analityka
Read more about the article Ach ten opluty wodospad… czyli lessons learned ERP

Ach ten opluty wodospad… czyli lessons learned ERP

Opisane tu podejście często nazywane jest "kaskadowym" (waterfall - wodospad). Jest ono dość często wskazywane jako powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości problemów jest nie tyle "wodospadowe" podejście, ono jak widać z powyżej opisanego procesu, ma głęboki sens, co wzięcie sobie na barki projektu (zawarcie umowy z dostawca na trzy lata to przyjęcie w dniu jej zawarcia harmonogramu łamiącego opisana powyżej zasadę) na lata zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał.Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju "nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go". To nie ma prawa się udać...A nasze "lessons learned"? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projektu prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane etapy) są znacznie bardziej odporne na kłopoty.

Czytaj dalejAch ten opluty wodospad… czyli lessons learned ERP
Read more about the article Business Model vs. System Model

Business Model vs. System Model

Swego czasu pisałem o tym, że np. klasa przechowująca informacje o pracowniku raczej powinna nazywać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo projekt systemu zawierający informacje o pracownikach i klientach, a także treść wielu dokumentów, powinien pozwalać zrozumieć co jest "w systemie" a co w "rzeczywistości" (pracownik jest żywym organizmem, oprogramowanie co najwyżej zarządza danymi opisującymi tego pracownika). Ku mojemu zaskoczeniu ale także radości, niemalże ten sam problem poruszył Ron Ross (bloger i autor książki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules): To make a long story short, business models talk directly about real-world things (as business people do);…

Czytaj dalejBusiness Model vs. System Model
Read more about the article Czym jest jakość oprogramowania… a może od czego ona zależy?

Czym jest jakość oprogramowania… a może od czego ona zależy?

Coraz częściej utożsamiam analizę z projektem gdyż w sumie produktem analizy jest jakiś projekt czyli model tego co analizowano, model tego co rekomenduję by powstało. Analiza sama z siebie nie jest samowystarczalna (to znaczy samo analizowanie nie jest wartościowym produktem samym w sobie). Problemy z projektami obserwuje nie ja jeden. W każdym kolejnym projekcie staram się szukać przyczyn, zrozumieć problem i podjąć próbę rozwiązania. Problem w zasadzie jest znany. [...] Dalej mamy same dobre rady, z którymi trudno polemizować:Wysoka modularność, współpraca wielu niezależnych, lub luźno powiązanych elementów, możliwość wymiany małych części, lub tworzenie różnych wariantów tego samego modułu, to podejścia, które przyniosą nam wartość dodaną. Ludzie mający do czynienia z monolitami (układ: jedna wielka baza danych i do tego wielki serwer aplikacyjny) z reguły postrzegają podejście rozproszone (dziesiątki lub setki małych kawałków fruwających gdzieś w koło) jako trudniejsze, bardziej skomplikowane i przez to gorsze i bardziej ryzykowne. Takie spojrzenie to postawienie sprawy do góry nogami.I tu moim zdaniem autor ma 100% racji. Nie ma chyba nic gorszego niż uznanie, że "jeden wielki zintegrowany system" to zaleta tego Systemu, jest to jego największa wada.

Czytaj dalejCzym jest jakość oprogramowania… a może od czego ona zależy?
Read more about the article Znajomość branży klienta szkodzi a nie pomaga…

Znajomość branży klienta szkodzi a nie pomaga…

Jakie doświadczenie i gdzie jest potrzebne I teraz pytanie jakie architekt budowlany musi mieć doświadczenie, jeżeli chce zaprojektować most? Wypadało by nie był to jego pierwszy most, ale czy musi znać miasto, w którym ten most powstanie? Czy musi mieć "doświadczenie kolejowe" dlatego, że to most kolejowy? Raczej nie, powinien mieć doświadczenie w projektowaniu mostów.Dlatego ktoś, kto ma rolę analityka i projektanta w projekcie, powinien mieć bardzo duże doświadczenie w analizie i projektowaniu, ale znajomość konkretnej branży nie wnosi tu żadnej wartości dodanej, a biorąc pod uwagę fakt, że rutyna zabija, potrafi być wręcz szkodliwe.Jeżeli to zamawiający oczekuje analityka z doświadczeniem w swojej branży, nie raz kieruje się on przypuszczeniem, że to ułatwi komunikację z nim. Jednak problem tkwi nie w znajomości branży a w komunikatywności ogólnie. Analityk powinien się cechować bardzo dobrymi zdolnościami komunikacyjnymi a nie znajomością konkretnej branży (wtedy raczej ryzykuje popadniecie w slang branżowy, co raczej przeszkadza niż pomaga).Z perspektywy dostawcy rozwiązań, popularyzującego tezę, że "on jest lepszy bo ma wiedzę z danej branży", jest to raczej próba stworzenia sztucznej bariery wejścia dla konkurentów, bo z wyżej opisanych powodów trudno o inne uzasadnienie... Zwróćmy uwagę, na to, że firmami, poza nielicznymi wyjątkami, zarządzają specjaliści od zarządzania. Branża ich doświadczeń ma tu drugorzędne znaczenie bo konkretny rynek musi znać dyr. marketingu a nie prezes firmy, ten drugi musi się umieć z tym pierwszym dogadywać. Inżynierowie dziedzinowi w roli prezesów, Ci częściej doprowadzają swoje firmy do upadku...

Czytaj dalejZnajomość branży klienta szkodzi a nie pomaga…
Read more about the article Sprzedam Ci prawa do kodu czyli wielka ściema

Sprzedam Ci prawa do kodu czyli wielka ściema

A może chcecie prawa do kodu źródłowego?A jasne, możemy chcieć. "No to zapłaćcie za to prawo". A przepraszam za co teraz? Kod, który powstał to utwór zależny, jest więc chroniony i już mamy na niego wyłączność, nie musimy ekstra za to płacić. Ale nie chcemy tego sami pisać (kodować) jeszcze raz. No dobrze, patrzymy na faktury, a tam jest kilkaset godzin programistów. Czyli co? Już zapłaciliśmy za ich pracę, za ten kod! Wystarczy!Kiedy pojawia się problem?W większości przypadków z jakimi się niestety spotykam to projekty, w których nie powstała opisana tu dokumentacja. Jaki mamy efekt? No jest kod, wszelkie prawa do niego i jego logiki ma wykonawca (jest autorem całości). Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych podlega wyłącznie ochronie jako dzieło literackie, jednak niestety to-co-program-ma-robić to tylko idea, a ta nie podlega ochronie (stwierdzenie faktu, że wystawiamy faktury, jako treść, nie stanowi żadnego zdatnego do ochrony tajemnicą firmy know-how). Tak więc wszelkie prawa do kodu ma w takim wypadku programista bo sam od zera to napisał (kod).Pada propozycja: za dodatkowe pieniądze sprzedamy prawa majątkowe do kodu, będziecie się Państwo czuli bezpiecznie. I teraz pytanie: jaką wartość ma nieudokumentowany kod oprogramowania? Tysiące linii kodu programu, nie raz kilka milionów, pisany bez projektu w wielu iteracjach. Mamy którąś tam jego wersję, w końcu powstawał w bólach, wielokrotnie modyfikowany, bez projektu. Nakład pracy znacznie przewyższający jego przepisanie. Kto i jakim kosztem będzie ten kod analizował by go zrozumieć i rozwijać? Ten kod, bez jego autora, jest BEZWARTOŚCIOWY a My, bez tej opłaty, nie mamy żadnych praw do tego za co zapłaciliśmy (poza licencją czyli prawem do korzystania).Tak więc niejednokrotnie oferta na sprzedaż praw do kodu to zwykła ściema!

Czytaj dalejSprzedam Ci prawa do kodu czyli wielka ściema
Read more about the article Krótki wpis o śladowaniu

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 dalejKrótki wpis o śladowaniu

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy
Starsze wpisy