Roczne archiwa: 2012

Read more about the article Model jako symulacja – także w analizie i projektowaniu oprogramowania

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 dalejModel jako symulacja – także w analizie i projektowaniu oprogramowania
Read more about the article Analiza oddziaływania i jakość modelowania

Analiza oddziaływania i jakość modelowania

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 dalejAnaliza oddziaływania i jakość modelowania
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
Read more about the article Prawo a wymagania …

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 dalejPrawo a wymagania …
Clip Art Gallery created by Mark A. Hicks, illustrator.

Wiedza po studiach… krótko

Niestety obecna "kadra analityczna" wielu firm, także ta "samodzielna freelancerska" to rzesza ludzi władająca pseudowiedzą. Na rynku księgarskim królują poradniki w rodzaju "analityk biznesowy w trzy tygodnie", po audytach dokumentów spotykam się z argumentami w rodzaju "ale ja mam certyfikat analityka po dwudniowym kursie i tam tak pokazywano". O testach egzaminacyjnych już nie będę pisał bo nie ja jeden uważam, że to odmóżdżanie a nie kontrola wiedzy."Drodzy Młodzi Przyjaciele. Czuję się w obowiązku zwierzyć się Wam z bardzo przykrej tajemnicy. Nie jesteście - większość z Was - dobrze wykształceni, a jedynie tak Wam się wydaje. Zostaliście oszukani najpierw przez nauczycieli, a potem przez wykładowców" - wyznaje Jan Stanek, profesor fizyki z Uniwersytetu Jagiellońskiego

Czytaj dalejWiedza po studiach… krótko
Read more about the article Procesy biznesowe lepiej z regułami biznesowymi i zasobami

Procesy biznesowe lepiej z regułami biznesowymi i zasobami

W wielu firmach system zarządzania jest tak niespójny, że jedynym sposobem funkcjonowania tych firm, jest łamanie zasad przez jej pracowników. Niestety pierwsza wpadka często powoduje załamanie się całego systemu (a nie raz i firmy). Wiele Zarządów firm nie zdaje sobie nawet sprawy z tego, jak duże jest ryzyko ciągłości funkcjonowania ich firm.Tak więc model procesu to nie algorytm działania firmy, wykazano nie raz, że algorytmizacja pracy ludzi jest niecelowa (wtedy stosujemy roboty).Znaczna część tego co robią ludzie to efekt ich kompetencji, wiedzy i doświadczenia, a nie dyktowania im jak mają wykonywać swoja pracę.Jeżeli wybierzemy drogę modelowania tego wszystkiego diagramami, to ilość tych diagramów szybko przekroczy granicę sensy całego projektu: nie będą czytane. Ich wartość będzie żadna.W procesie dobrze przygotowanej analizy (jakiejkolwiek) modele tworzy się by je badać, a nie tylko po to by powstały za pieniądze sponsora projektu.Należy też nabrać pokory: większość organizacji sprawnie funkcjonuje nie mając żadnych modeli procesów, więc teza, że ich brak szkodzi jest nie do obrony. Po co więc te modele? Żeby zrozumieć dlaczego tak jest i co się stanie, gdy zechcemy wprowadzać zmiany.

Czytaj dalejProcesy biznesowe lepiej z regułami biznesowymi i zasobami

Refleksje – IT w czasach nowych wyzwań rynkowych

Tu należy się uwaga, że znaczny udział usług to obecnie usługi związane z tworzeniem oprogramowania tak zwanego dedykowanego lub jego dostosowywania. Moim zdaniem można uznać prognozę IDC z 2003 roku za trafioną. Obserwując nie tylko przetargi proporcje te wydają się jak najbardziej trafne.Warto zwrócić uwagę, że obecna złożoność oprogramowania wspomagającego biznes, praktycznie uniemożliwia skuteczne wdrożenie bez wsparcia. Czasy gdy kupujący "sam sobie coś zrobił" raczej bezpowrotnie minęły. To co obserwuję, to migracja znacznej części usług z obszaru technologicznego (główny problem to instalacja i uruchomienie) do obszaru biznesowego (główny problem to zmiana organizacji jaką powoduje wdrożenie nowych narzędzi IT).Na tym etapie pojawia się potrzeba poprzedzenia instalacji oprogramowania (wybór, zakup i wdrożenie) analizą i prognozowaniem (predykcją, przewidywaniem) skutków tego wdrożenia. Bardzo istotne jest, nie to czy produkt "zadziała" a to do czego planujemy go użyć i czy się sprawdzi.

Czytaj dalejRefleksje – IT w czasach nowych wyzwań rynkowych
Read more about the article Emerytury… Idealizacja czyli mechanizm systemu solidarnościowego

Emerytury… Idealizacja czyli mechanizm systemu solidarnościowego

[uzupełnienie grudzień 2021] Nie planuję tu analizy obecnej reformy emerytalnej. Tu (źródło poniższego cytatu) można zapoznać się z jedną z wielu opinią o ZUS. Polecam cały tekst a tu wstęp, który posłużył mi za inspirację do tego tekstu: Kluczowym elementem logiki ekonomicznej jest ujmowanie zagadnień w kategoriach strumieni i zasobów łącznie. Domański słusznie zwraca uwagę, że analizowanie miejsca systemu emerytalnego w gospodarce tylko w kategoriach podziału PKB, a więc strumieniowo, jest błędne. Powinno się bowiem uwzględniać konsekwencje kapitałowe współudziału w tworzeniu przez pracujących majątku gospodarczego, rozumianego całościowo (np. łącznie z…

Czytaj dalejEmerytury… Idealizacja czyli mechanizm systemu solidarnościowego
Read more about the article W strefie parkowania mandat się opłaca – czyli analiza systemowa … nie wykonana

W strefie parkowania mandat się opłaca – czyli analiza systemowa … nie wykonana

Jak było by "lepiej"? Kara powinna niszczyć "wygraną" parkującego tak więc powinna wynosić co najmniej 31,20zł zamiast ustalonej 25zł (minimalna opłata plus kara powinna być równa co najmniej opłaci należnej). Z uwagi na to, że rolą kary jest nie tylko niszczyć korzyść za łamania zasad ale także odwodzić od ich łamania, powinna być odczuwalnie (co by to tu nie miało znaczyć) wyższa. Nie będę się tu rozwodził się nad tym, jaka powinna być, inny jest cel artykułu (zainteresowanym teorią gier polecam na początek np. książkę [[Konkurencja i kooperacja. Teoria gier w ekonomii i naukach społecznych. Malawski, Wieczorek, Sosnowska]]).Chce pokazać, że projektowanie systemu opłat i kar powinno być przeprowadzone "profesjonalnie" a nie po amatorsku. System powinien być tak zaprojektowany by nie demoralizował i by był skuteczny. Radni będą, jak zadeklarowali, zmieniali system kar. Ale niestety ośmieszyli się w oczach obywateli i stracili znaczne środki (6,20 za każde źle opłacone parkowanie).Teza mówiąca "brzydko jest być nieuczciwym" raczej rozśmiesza, bo to prawda, że brzydko, ale nie zmienia to faktu, że ekonomia jest bezlitosna i na pewno ludzie (wielu) znajdą "wygrywającą" strategię, jeżeli tylko taka istnieje. Innymi słowy skoro miasto pobiera dwie różne opłaty za tę sama usługę (z karą i bez), wybrana zostaje wersja o niższej opłacie.Powyższe to namiastka zjawiska "psucia" prawa i niestety demonstrowania niekompetencji urzędników. Sam fakt, że tego nie przewidzieli wystawia im słabe świadectwo. A co dopiero w przypadkach bardziej złożonych?Urzędnicy, skoro już nie mają tych kompetencji, powinni uczyć się korzystać z pomocy specjalistów. I nie tylko oni...

Czytaj dalejW strefie parkowania mandat się opłaca – czyli analiza systemowa … nie wykonana
Read more about the article No to była mała porażka… piszę ku przestrodze

No to była mała porażka… piszę ku przestrodze

Nie będę tu opisywał szczegółów tego projektu, ważne są wnioski a nie ta czy inna firma:pominięcie któregokolwiek etapu projektu analitycznego, w szczególności pierwszego, powoduje, że całość staje się nieweryfikowalna, ryzyko rośnie, ukrycie prawdziwego celu projektu przed analitykiem (jest to możliwe, jeżeli dojdzie to tego co powyżej) powoduje, że większość jego czasu pracy nie służy projektowi, po zanegowaniu efektów pracy analityka, obrona takiego projektu jest niemożliwa bo brak kluczowego narzędzia: śladowanie (przypomnę, że usunięto pierwszy etap - zdefiniowanie celu). Co było prawdziwym celem projektu? Okazało się, że "nie chcemy by przetarg wygrała firma XXX i jej produkt". W trakcie pierwszych problemów z "uznaniem" specyfikacji wymagań dostałem listę wad posiadanego oprogramowania. Ku mojemu zaskoczeniu były tam nawet błędy rachunkowe (inne tu pominę, choćby niezgodność programu z prawem). Pytam: jakim cudem to zostało odebrane i zapłacone? Cóż...

Czytaj dalejNo to była mała porażka… piszę ku przestrodze

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy
Starsze wpisy