Czy Pan to robi lepiej?

Zadano mi niedawno po raz kolejny dość trudne pytane: Czy Pan to robi lepiej od dużych firm doradczych? Po pierwsze zapytałem "co". I tu pojawił się problem. Z zamiarem napisania tego artykułu nosze się od pewnego czasu, i w końcu rosnąca częstotliwość zadawania tych pytań skłoniła mnie do tego aktu "odwagi". Ja sam zadaję to pytanie spotykanym przedstawicielom dużych firm doradczych a także w kuluarach konferencji, na których nie raz ich spotykam. Zawsze dostaję tę sama odpowiedź: Jarek, Ty i my oferujemy zupełnie inny produkt. Przekopałem się przez oferty "wielkiej…

Czytaj dalejCzy Pan to robi lepiej?

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

Udziałowcy projektu czyli który diagram UML …

Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu. UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań. Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią "korzeń" modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.

Czytaj dalejUdziałowcy projektu czyli który diagram UML …

Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

W projektach informatycznych najczęściej spotykamy: analityka wymagań (AW), analityka systemowego (AS), dewelopera w tym architekta systemu (D). W zasadzie trudno powiedzieć co jest produktem każdego z nich. Najczęściej AW dostarcza jakiś opis tego czego oczekuje klient, AS robi porządkuje to zrobił AW np. z pomocą przypadków użycia a D bierze to do ręki i musi zaprojektować i wykonać oprogramowanie. Jak widać, odpowiedzialność za to co powstanie jest rozmyta. Klient najpierw przekazuje swoje oczekiwania AW zaś otrzymuje produkt od D. Konia z rzędem temu, kto mi powie jak tego dokonać bez permanentnych iteracyjnych wyjaśnień i bombardowania Klienta pytania w rodzaju "co Państwo mieli na myśli pisząc...".

Czytaj dalejSprawna Inżynieria Oprogramowania: Ekstremalna obiektowość

Koniec treści

Nie ma więcej stron do załadowania