Analityk biznesowy, współpracujący ściśle z kierownikiem projektu, ułatwia radzenie sobie z wyzwaniami biznesowymi. Jednakże, podczas gromadzenia wymagań dla nowego lub już istniejącego projektu, analityk biznesowy musi mieć na uwadze, że każdy projekt może wymagać stworzenia i przeprojektowania towarzyszących mu procesów. Analityk biznesowy musi więc działać jako nośnik zmiany, aby sprawić, że nowo wprowadzane procesy nie tylko zwiększają sukces projektu, lecz także zwielokrotniają szanse projektu na osiągnięcie celów biznesowych organizacji.
? 70% of all project failures are as a result of poor requirements.
? There is a 60% time and cost premium to be paid on projects with poor quality requirements.
? As the projects get more interdepartmental and complex, the failure rate rises.
? It costs 80 times as much to fix defects after delivery, than at the specification stage.
? 74 per cent of all companies have immature requirements practices.
? Large scale systems project fail with alarming regularity. A typical project over-ran its budget by 189% and over-ran its schedule by 222%.
? Average project has about 30% rework. This means that for every Kshs 1,000,000, Kshs 300,000 is spent redoing something that was thought to be complete.
? The average company with low requirements maturity wastes 34% of the organization?s IT development budget.
? 68% of companies simply did not use the necessary competency in requirements discovery at the start of their project to assure project success.
Source: IAG Business Analysis Benchmark, 2008 (za HARD FACTS ON BUSINESS ANALYSIS | LinkedIn).
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.
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…
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.
