Według Forrester zmieniający się porządek zapotrzebowania na specjalistów IT wynika głównie z trzech rzeczy: Coraz większa popularność różnych technologii i rozwiązań jak np. SaaS (Software -as-a-service) bądź Business Intelligence, które…
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".
Po co nam CASE? Bo Dzięki narzędziom CASE projekty tworzy się dokładniej, a praca nad diagramami, sprawdzanie ich poprawności oraz śledzenie wykonanych testów jest prostsze i szybsze. (wiecej: http://www.eioba.pl) Tak więc gorąco polecam stosowanie narzędzi (lista narzędzi CASE). Z zasady nie reklamuje oprogramowania. Uważam, że jego sprzedawanie to inna kompetencja. Jednak nie da się ukryć jestem użytkownikiem "czegoś". Czym to jest? Pakiet typu [[CASE]] [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgrade i... mamy burzę mózgów :):
Tak więc moim zdaniem budżet zamawiającego to wiedza zamawiającego, której nie musi ujawniać. Skoro już jej nie ujawnia to powinien mieć kompetencje (własne lub wynajęte) pozwalające po pierwsze opisać projekt, po drugie zdefiniować (opisać) "to coś informatycznego" co pomorze mu ten projekt zrealizować. Wyjawienie przez klienta planów i budżetu takiemu dostawcy to postawienie się pod ścianę w negocjacjach z nim. Dlatego nie ma sensu sytuacja gdy dostawca pyta klienta o jego budżet czy oferowanie mu czegokolwiek. I nie ma tu znaczenia uczciwość tego dostawcy bo z perspektywy klienta sprzedawca na prowizji stanowi duże ryzyko dla rzetelności takiej oferty. I na koniec: napisanie tylko: "system ma wystawiać faktury VAT" jako opis tego co chcemy kupić nie ma żadnego sensu bo to stanowczo za mało by cokolwiek wycenić i ocenić.... ale też napisanie, że "kontrahenta można dodać do faktury z rozwijanej listy uruchamianej prawym klawiszem myszy", jest jeszcze większym błędem, bo po pierwsze nie raz narzuca wspomnianą kastomizacje (a to podnosi koszt), a po drugie bywają lepsze sposoby rozwiązania tego problemu. Dla gotowego systemu nie ma sensu pisanie aż takich szczegółów, a dla dedykowanego robi się to zupełnie inaczej.
To, że UML jest obcy większości analityków biznesowych to przykra prawda, dzisiaj raczej źle świadcząca o tej większości (patrz model kompetencji analityka biznesowego IIBA). Używanie UML do modelowania procesów biznesowych jest ograniczaniem możliwości tych modeli gdyż UML reprezentuje paradygmat obiektowy a BPMN procesowy a to dwa odrębne światy (to, że powstały i są wykorzystywane równolegle te dwie, różniące się od siebie, notacje notacje także o tym świadczy). Trudno także mówić o "podejściu" do modelowania procesów w UML bo to tak, jak by mówić że "łodzie reprezentują zupełnie odmienne podejście do poruszania się po drogach publicznych". Niestety są żeglarze, którzy nie uznają innej prawdy niż ta, że łodzią można wszędzie, trzeba się tylko postarać. Faktem jest, trzeba się dobrze postarać. [...] Co do wymagań samych narzędzi UML nie podejmuję się dyskusji bo narzędzia są rożne i każdy sam sobie je dobiera. Co do samej ścieżki analizy to raczej w pierwszej kolejności modelujemy biznes (modele BPMN) a potem dopiero zastanawiamy się i projektujemy narzędzie, oprogramowanie dla tego biznesu czyli pora na UML. Odwrotną kolejność sugerują dostawcy gotowego oprogramowania ale ten wątek był na tym blogu już nie raz poruszany.