Wypowiedzi
-
Jarosław Ż.:
Obecnie odchodzi się pojęcia "analityka systemowy" bo wprowadza zamęt kompetencyjny. Co do certyfikatów to większość złych diagramów UML jakie widują w toku audytów robili ludzie z certyfikatami, Należy się uczyć metod analizy a potem notacji... certyfikat niczego nie gwarantuje tak samo jak Prawo jazdy nie gwarantuje przestrzegania przepisów na drodze.
Zgoda, certyfikat nie gwarantuje metod analizy - daje jedynie sposobu wyrazu
tego co chcemy przekazać w postaci modelu. To jak umiejętność pisania wierszy,
notacja to znajomość struktury, zasady poprawnej gramatyki i ortografii,
natomiast sama metodyka i doświadczenie jak je stosować to wena i talent :-)
zarówno w SCRUM (rola Product Owner) jak i w IIBA (Business analyst) to osoby, których rola jest zrozumieć organizację, zrozumieć jaki produkt jest jej potrzebny i opisać ten produkt najlepiej z pomocą modeli (bo są dużo bardziej precyzyjne i dają się weryfikować, niż proza)
Co istotne precyzyjne modele w sytuacji dobrze zdefiniowanych transformat pozwalają przejść wmiarę bezproblemowo pomiędzy poszczególnymi modelami (PSM/PIM/PSM) utrzymując śladowalność elementów na każdym poziomie.
Dobrym wytłumaczeniem jest MDA:
Racja raczej miałem na myśli, że pochodzenie obu notacji BPMN i UML wywodzi się z tego samego systemu pojęciowego.
- analityk jako produkt oddane model PIM: to wymaganie mówiące "tak ma to działać"
- developer na tej podstawie tworzy oprogramowanie: implementuje PIM i realizuje wymagania pozafunkcjonalne.
(MOF nie jest notacją, tylko systemem pojęciowy, notacja do zestaw symboli, w UML 2.5 zostało to już uproszczone, zniknął nawet podział na Superstructure i Infrastrukturze).Jeśli chodzi o REQB przyznam nie spotkałem się z wymaganiem tego certyfikatu (np. do przetargów), zawsze opierałem się o BaBoK i RUP'a jeśli chodzi o zarządzanie wymaganiami.
A tego akurat nigdy nie rozumiałem , jeżeli ktoś używa Use Case i reszty UML do analizy i projektowania to mu REQB na plaster, RUP to dinozaur z czasów lat 90-tych i uczenie się tego teraz to cofanie się.
Czasem w przypadku koncepcji wymagane jest, aby wymagania wyższego rzędu były zformalizowane w postaci modelu, by utrzymywać ich spójność (szczególnie, gdy mamy nie konieczne przychylne sobie jednostki orgnizacyjne), przy całym programie wieloetapowych zmian w wielu systemach, zmiana ma osiągnąć konkretne cele - już na etapie koncepcji pojawia się potrzeba gromadzenia wiedzy -np. mamy prostowane procesy wynikające ze zmian prawnych, pojawiają sie wymagania interesariusza - trzeba je zwalidować, by projekt nie stał się koncertem życzeń, Walidacja taka nie jest prosta bo często definiowane przez interesariusza jest jakaś wizja rozwiązania, które nie zawsze będzie najlepsza - może to wprowadzić sporo zamieszania w projekcie, szczególnie, gdy interesariusz się zafiksuje i nie przyjmuje innych rozwiązań.
Często dopiero na takiej warstwie, po ocenie i zdefiniowaniu wymagań wyższego rzędu można dopiero definiować wymagania rozwiązania.Nie podejmuję się dyskusji z obszaru 'są wymagane w przetargach" bo to zawsze dyskusja pozamerytoryczna.
Wychodząc z tego założenia - żaden certyfikat nie jest potrzebny - wystarczy znać i umieć stosować, niestety są czasem wymogi formalne, a to czy są dobrze zdefiniowane to już zupełnie inna bajka :-). -
Justyna N.:
Witam , nie wiem gdzie zamieścić to pytanie, ale jak bardzo przydatne są certyfikaty
REQB Foundation i OMG Certified UML Professional na rynku pracy Analityków IT? Warto w nie inwestować czy dać sobie spokój i w przypadku nadmiaru czasu i chęci poznawczych ponownie rozważyć robienie?
Jeśli Analityk IT pełni rolę Analityka Systemowego to dobra znajomość UML - szczególnie potwierdzona certyfikatem wydaje mi się niemal musowa, akurat na tym polu UML w zasadzie deklasuje konkurencyjne notacje jeśli mówimy o totalnie neutralnym środowisku.
Inaczej już się ma w przypadku Analityka Biznesowego tutaj BPMN nie ma aż tak dobrej pozycji (albo raczej wciąż na polskim rynku ma sporo konkurencji od ArchiMate po starego ARIS'a wciąż używanego w niektórych instytucjach, choć wciąż wydaje mi się najwygodniejszą notacją (BPMN) - wynika to pewnie z wspólnej notacji (z UML) narzędnej poziomu L3 - MOF - Meta Object Facility czyli notacja w której obie notacje są napisane. Pozwala to na bezproblemowe powiązanie obu modeli.
Jeśli chodzi o REQB przyznam nie spotkałem się z wymaganiem tego certyfikatu (np. do przetargów), zawsze opierałem się o BaBoK i RUP'a jeśli chodzi o zarządzanie wymaganiami. -
Spotkałem się, w przypadku niektórych klientów, świadcząc usługi B2B, z wymogiem posiadania takiego Ubezpieczenia. Niestety nie doszło do współpracy toteż nie mogę się wypowiedzieć o kosztach/korzyściach płynących z niego.
-
W zasadzie dodałbym jeszcze jeden etap pomiędzy specyfikacją wymagań zgodnych z potrzebami, a architekturą oprogramowania, bazując na Model Diven Architecture (MDA - http://pl.wikipedia.org/wiki/Model_Driven_Architecture):
CIM będzie zawierał potrzeby osadzone w istniejących/zmodyfikowanych procesach (zależy od podejścia czy według TOGAF'a czy bardziej według Zachmana) - słownie nie skomputeryzowana - niezależna od komputera.
PIM - brakująca warstwa - imo bardzo często ignorowana nawet w dużych projektach, co potem jest bardzo kosztowne w momencie zmiany technologii - Platform Independent Model - czyli Model niezależny od platformy - funkcjonalny najczęściej modelowany w postaci Przypadków Użycia z przebiegami\scenariuszami oraz Model danych, którym te PU operują.
PSM - Platform Specify Model - Model w konkretnej technologii - logiczny i fizyczny implementacji.
Tyle w offtopie.
Zarobki są bardzo zróżnicowane tak samo jak czasem podejście PMów do analityków. Częściowo odpowiada za to tworzenie z testerów "analityków", takie decyzje często w projektach zapadają i mamy potem takiego potworka w dokumentacji, gdzie Przypadki Użycia tworzone są na podstawie Test Case'ów, a dokumentacja analityczna jest tworzona "bo Klient chce, by mieć d***krytkę jak przyjdzie kontrola, zresztą i tak tego nie czytają". Takie niestety mamy realia, zwłaszcza w publiku. Ze świecą szukać świadomych klientów.
Przez to czasem się odechciewa, jak modyfikacja realny rozmiar ma 393 CFP, a w modelu rozdrobnienie do zmiany 3000 PU+, bo "analityk" robił model, a kasa się potem zgadzała bo rozliczaliśmy w IFPUG'u i wymnożyliśmy formatki przez role - straszne patologie czasem odchodzą.Ten post został edytowany przez Autora dnia 16.04.15 o godzinie 18:27