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

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".

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

Co zrobić przed wyborem dostawcy usług IT?

Jednak powyższy fragment, waga procesu opisu wymagań, stanowi tylko 8% całości tekstu, którego autorem jest firma dostarczająca dedykowane rozwiązania. Dlaczego? Może rzecz w tym, skoro analiza potrzeb (patrz powyżej) powinna być wykonana przed wyborem rozwiązania i jego dostawcy to wniosek nasuwa się sam: nie robi tego ten dostawca i słusznie. Tak więc z dużym prawdopodobieństwem można przyjąć, że "określanie potrzeb" nie jest mocną stroną firm, które dostarczają konkretne rozwiązania :). Skoro więc "Punktem wyjścia w procesie doboru dostawcy usług IT jest precyzyjne określenie własnej potrzeby w tym zakresie ", to gorąco zachęcam Państwa do precyzyjnego określania swoich potrzeb przed wyborem partnera, który je zrealizuje.

Czytaj dalejCo zrobić przed wyborem dostawcy usług IT?

Prawo autorskie, szpiegostwo przemysłowe i projektowanie

Jak ustrzec się przed wyniesieniem z firmy tajemnicy jej funkcjonowania, tworzonej latami organizacji, procedur i procesów, reguł biznesowych? Jak zatrzymać w firmie wiedzę mino zamawiania oprogramowania, które siła rzeczy ja zawiera? Problem nie jest prosty. Sami prawnicy nie są między sobą zgodni co do tego, gdzie leży granica pomiędzy utworem literackim a szczegółowym opisem rozwiązania. Wydaje się, że kluczem jest to sposób tworzenia opisu tego co ma powstać. Standardem w IT jest opis wymagań, ten jednak z urzędu czyni autora oprogramowania także posiadaczem opisu logiki w nim zawartej, bo on jest autorem jej opisu. Wyjściem wydaje się zawarcie w umowie nie opisu wymagań na oprogramowanie a projektu oprogramowania. Metodą zdefiniowania granicy, za którą mamy nie utwór literacki (specyfikacje wymagań) a projekt wraz z algorytmami, jest metodyka MDA. Wtedy firma realizująca zamówione oprogramowanie tworzy dzieło zależne a zamawiający nie traci panowania nad tak powstałym produktem. Jest to sytuacja jaką znamy w branży budowlanej: developer dostaje projekt architektoniczny, i sam fakt, że postawił na jego podstawie obiekt nie daje mu żadnych praw do niego, gdyż wystarczająco szczegółowy projekt obiektu pozostaje dziełem projektanta a nie jego wykonawcy. Jednak zawsze, bo nie ma złotej reguły, wymaga to konsultacji i szczegółowego określenia zawartości dokumentacji, która ma stać się "opisem przedmiotu zamówienia".

Czytaj dalejPrawo autorskie, szpiegostwo przemysłowe i projektowanie

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ść

Analiza przedwdrożeniowa ? czym jest

...do czego zmierzam? Do tezy, mówiącej: skoro dostawcy oprogramowania zaczynają od opracowania koncepcji wdrożenia swojego produktu, to ktoś powinien przed nimi opracować specyfikacje potrzeb. Aby powstała specyfikacja potrzeb powinien ktoś zdefiniować problem, wskazać możliwe rozwiązania i ocenić jego wykonywalność. Nie ma także sensu szukanie problemu na siłę tylko po to, by wdrożyć jakieś oprogramowanie bo jego sprzedawca tak chce. Dostawcy gotowego oprogramowania powinni się w końcu pogodzić z prostym rynkowym faktem: to oni są wybierani a nie oni wybierają, dokładnie tak jak każdy inny produkt na rynku.

Czytaj dalejAnaliza przedwdrożeniowa ? czym jest

Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa – gdzie różnica?

Tak więc analiza wymagań to jest praca wykonana by opisać czego oczekujemy i dokonać wyboru. Analiza przedwdrożeniowa to praca wykonywana przez dostawcę, którego wybrano, w celu opracowania specyfikacji prac jakie należy wykonać by wdrożyć dany produkt. Dobrze wykonany model nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt wykonania modelu a także nie raz stanowią zbędne ograniczenia. Użycie takiego modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne: wystarczy go rozesłać do dostawców i zapytać po pierwsze czy ich system pasuje do niego, jeżeli tak to ile kosztuje ten produkt rok po roku. Z takim modelem kupujący nie musi udowadniać, że jego oczekiwania mają sens (co nie raz zdają się podważać dostawcy) a dostawca musi zdeklarować, że jego produkt pasuje do modelu.

Czytaj dalejWymagania na oprogramowanie ERP a analiza przedwdrożeniowa – gdzie różnica?

Sprawne zarządzanie i właściwie dobrany system informatyczny to warunek sukcesu?

W obecnej ekonomii jedne firmy przegrywają inne osiągają sukcesy. Jeśli chcesz być jednym z tych, którzy osiągają sukcesy musisz umieć zaadresować każde swoje działanie na rynku. Jedną z podstawowych zasad strategii rynkowych jest właściwa segmentacja rynku. Podobno wie o tym każdy menedżer i niestety prawie każda firma próbuje powiększać przychody zaniedbując te zasadę. Jak na rynku adresować swoje produkty?

Czytaj dalejSprawne zarządzanie i właściwie dobrany system informatyczny to warunek sukcesu?

CRM…

Wydaje mi się, że oferowanie jakiegokolwiek CRM'a metodą "mamy dobry system, przekonaj się o tym kupując go" jest dużym błędem. Skuteczniej było by oferować go strategią "na garnuszek miodu" czyli: poznać firmy (rynek, swoich potencjalnych klientów), odkryć ich kłopoty, opublikować informację o kluczowych cechach oferowanego systemu CRM, ci którzy go potrzebują znajdą go wystarczy tylko właściwie promować się.

Czytaj dalejCRM…
plac budowy
źródło: http://www.geotor.pl/przemysl.htm

User story – kłopoty

Tak więc wymagania na oprogramowanie powinny być określone przez dialog biznesowy zaś specyfikacja oprogramowania przez dialog technologiczny. I tu łyżka dziegciu: wiele razy byłem świadkiem gdy to zamawiający psuł projekt uważając, że wie lepiej jak się tworzy oprogramowanie. Zjawisko to (tu bardzo niebezpieczne dla życia ludzi) także zna inżynieria budowlana dlatego prawo budowlane wymaga projektu architekta a jego projekt chroni nie tylko prawo budowlane ale także i autorskie.

Czytaj dalejUser story – kłopoty

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację?

Czytaj dalejProjektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

Projekty IT ? patrz i uważaj?

Moim zdaniem mamy do czynienia z pewnym paradoksem epoki: firmy inwestują w oprogramowanie nie raz setki tysięcy złotych i więcej, statystyka wdrożeń pokazuje, że podczas wdrożenia najprawdopodobniej dopłaci drugie tyle jednak firmy te (za obopólną zgodą z dostawcą oprogramowania) oszczędzają z górą kilkanaście procent planowanego budżetu projektu wykreślając z projektu analityka, prawnika i negocjatora. Moim zdaniem jest to lobbing dostawców IT, którzy generalnie zarabiają na niekompetencji i braku doświadczenia kupujących (nie wszyscy na szczęście). Rozumiem, że wiedza ekspercka ma wartość na rynku (sam na tym rynku funkcjonuję) ale nie rozumiem wykorzystania tej wiedzy przeciwko własnym klientom?

Czytaj dalejProjekty IT ? patrz i uważaj?

Wymagania na oprogramowanie ERP wspomagające zarządzanie: dwie kupki

Najpierw analiza tego co i jak robimy. Potem podział tego na obszary standardowe, które obsłużymy narzędziem uniwersalnym, i pozostałe (których z reguły jest bardzo mało ale są bardzo ważne dla nas) i zróbmy je po swojemu ale nie pakujmy się w niszowe lub przestarzałe technologie. Nie dawajmy także wiary w to, że kupno tego co ma (powielenie tego co robi) nasz konkurent uczyni nas bardziej konkurencyjnymi bo praktyka pokazuje coś zupełnie odwrotnego.

Czytaj dalejWymagania na oprogramowanie ERP wspomagające zarządzanie: dwie kupki

Koniec treści

Nie ma więcej stron do załadowania