Opis Szkolenia (terminy szkoleń otwartych organizowanych przez eduFuturo) Prowadzący: Jarosław Żeliński (autor tego bloga). tel: 608 05 90 20) Cel szkolenia: Poznanie formalnych zasad dokumentowania wymagań na systemy, zarządzania zakresem projektu, analizy biznesowej.…
Po co nam UML? analiza i rozwiązanie problemu przed kodowaniem aplikacji jednoznacznie rozumiana wymiana wiedzy o problemie i o jego rozwiązaniu https://youtu.be/gNj8I4uSTgc?si=oA1XN650GBFB4ggB&t=1016 The Lost Art of Software Design ? Simon…
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…
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)
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.
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.
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!
"Jeśli chcesz opisać prawdę, elegancję zostaw krawcom."(A. Einstein) Poniżej wybrane moje wystąpienia. Regularnie dzielę się wiedzą na konferencjach, bywam zapraszany przez dostawców oprogramowania ERP by opowiedzieć ich klientom jak podejść…
