March 2012 – Page 2 – JZ IT Consulting Ltd

Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.

Post author:Jaroslaw Zelinski
Post published:8 March 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

zły model to złe oprogramowanie.... Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią. Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".

Certyfikacje w IT, chory system Prawa Zamówień Publicznych i nie tylko…

Post author:Jaroslaw Zelinski
Post published:7 March 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Swego czasu przewalała się w środowisku IT fala głosów za "certyfikacją zawodu informatyka". Po pierwsze pojawił się kłopot z definicją kim jest ów "informatyk", po drugie pojawił się kłopot z wykazaniem korzyści dla ogółu klientów, bo korzyść dla środowiska "informatyków" (co by to słowo nie miało tu oznaczać) jest prosta: ograniczenie dostępu do zawodu czyli jego monopolizacja. Zalety w rodzaju "podniesie się jakość usług" do mnie, i nie tylko do mnie, nie przemawiają. Nie wierzy w to nikt, kto ma w praktyce do czynienia z "certyfikowanymi" specjalnościami. Certyfikat (czyli po portu zdany test) to nic innego jak "wiem jak to robić" co nie ma nic wspólnego z "umiem to zrobić". Każdy (prawie) wie jak się biega, jak się robi zdjęcia, jak się śpiewa, wie (w końcu uczą tego w szkole podstawowej i średniej) jak się pisze książki i wiersze, wie .... większość z nas wie jak siw robi większość tego co mamy wokół siebie, czy jednak potrafimy? Certyfikaty itp. to w większości przypadków żadna gwarancja a nie raz wręcz odwrotnie.

Znaczenie ma nie wielkość projektu, a cykl jego życia…

Post author:Jaroslaw Zelinski
Post published:5 March 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty "na żywioł". Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany "maintenance") niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.

UML MDA czyli od biznesu do projektu logiki systemu

Post author:Jaroslaw Zelinski
Post published:2 March 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania "na papierze". Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich...). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: "czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da". W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: "ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów". W zasadzie taki proces analizy i projektowania jest znany od lat jako [[Model Driven Architecture]] (MDA). [...] Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman'a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD (Joint Application Development) to jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt. To jest właśnie problem nazywany "użytkownik nie wie czego chce". Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman'a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.