czerwiec 2012 - IT-Consulting Jarosław Żeliński

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

Post author:Jarosław Żeliński
Post published:26 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:3 komentarze
Post last modified:26 czerwca 2012

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 dalej

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

Post author:Jarosław Żeliński
Post published:24 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:9 sierpnia 2012

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

Analiza oddziaływania i jakość modelowania

Post author:Jarosław Żeliński
Post published:21 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:21 czerwca 2012

Model zawierający wyżej opisane śladowania (i tylko taki!) pozwala na analizę zalezności, np. chcemy dowiedzieć się na co ma wpływ Proces_2, wtedy powinien powstać np. taki diagram: Jak widać, śladowanie jest tu warunkiem koniecznym dlaczego? Taki model może powstać "automatycznie" (narzędzie do modelowania musi posiadać taka funkcjonalność). jednak to nie jedyny warunek: model musi zachowywać formalna poprawność, czyli nie używamy pojęcia Rola (pas na modelu procesów) do symulowania "systemu" który coś robi, bo oprogramowanie to narzędzie człowieka (rola w procesie), specyfika użycia danego narzędzia to umiejętności aktora (użytkownika) i jest to co najwyżej problem skojarzenia danej czynności (procesu) z dokumentem opisującym procedurę lub instrukcję użytkownika (to także narzędzie powinno umożliwiać). Wszelkie łamanie formalizmów notacji odnosi taki sam skutek jak np. wykorzystywanie pól w bazie danych do przechowywania innych danych niż te z nagłówka np. wpisywanie drugiego imienia do pola Nazwisko czy nazwy dzielnicy w pole Miasto. Z takiej bazy danych żaden sensowny raport już nie powstanie. Jeżeli na modelu procesów użyto symboli w innych znaczeniach niż to wynika z użytej notacji żadnej sensownej informacji też nie uzyskamy... to już nie modele tylko zwykłe obrazki.

Czytaj dalej

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

Post author:Jarosław Żeliński
Post published:18 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:9 komentarzy
Post last modified:17 czerwca 2012

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 dalej

Sprzedam Ci prawa do kodu czyli wielka ściema

Post author:Jarosław Żeliński
Post published:15 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:10 komentarzy
Post last modified:10 listopada 2021

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 dalej

Krótki wpis o śladowaniu

Post author:Jarosław Żeliński
Post published:13 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:13 lutego 2020

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 …

Post author:Jarosław Żeliński
Post published:11 czerwca 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:10 komentarzy
Post last modified:13 lutego 2013

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