Wprowadzenie

29 Lipca 2018 r. w Sopocie miało miejsce pierwsze popołudniowe spotkanie “Analiza Biznesowa 3 miasto” zorganizowane wspólnie z portalem Analiza.IT  a celem było “Stary analityk odpowiada na pytania młodych” :). W ramach podsumowania spotkania zebraliśmy pytania zdobywających doświadczenie analityków, wspólnie uznane za reprezentatywne.

Oto one i moje odpowiedzi. Starałem się niczego nie ukrywać, traktujcie to jak szczere koleżeńskie rady,  obciążone moim prawie 30-letnim doświadczeniem i subiektywizmem. Znajdziecie tu i troszkę inżynierii i technologii, i troszkę filozofii i troszkę etyki zawodu…

Zapraszam

Jarek Żeliński

F.A.Q. czyli Analitycy Biznesowi Pytają

Nowy analityk w korporacji, jak ma się zachować gdy wchodzi w nieuporządkowany projekt i niezbyt uporządkowane, chaotycznie tworzone “papiery”?

To chyba najtrudniejsze pytanie i najprostsza odpowiedź: ma być uczciwy względem siebie. Jeżeli wszedł w miejsce poprzednika by go po prostu zastąpić (analityk przyjął złożoną mu ofertę pracy), to pozostaje mu tego poprzednika zastąpić w sferze tego jak ten pracował i jakie dokumenty tworzył. Jeżeli ktoś został zatrudniony bo pracodawca uznał, że poprzednik robił coś gorzej a nowy pracownik ma wiedzę by poprawić dotychczasową jakość pracy, i być może wdrożyć nowe i lepsze praktyki, to znaczy że ma spełnić tę obietnicę ;).

Tu ważna uwaga: nie da się reformować firmy bez wiedzy i zgody jej zarządu a projektu bez wiedzy i zgody Kierownika Projektu. Można owszem “świecić przykładem”,  ale należy przy tym pamiętać, że to nie to samo co “robienie inaczej i lepiej niż inni”, bo tak można rozsadzić firmę (projekt) od środka.

Tak więc podejmując się nowej pracy należy przyjąć na siebie wszelkie wynikające z tego obowiązki, naprawianie świata należy robić zawsze za wiedzą i zgodą zwierzchników :). Jednak podstawowym, moralnym i etycznym zadaniem każdego z nas, jest informowanie przełożonych o dostrzeżonych ryzykach.

Czego i jak się uczyć, żeby zacząć pracować w analizie

Analiza biznesowa (analiza systemowa organizacji) i szukanie rozwiązań problemów, to praca bardzo podobna do pracy naukowej. Przyjęcie analizy systemowej jako fundamentu metod pracy, pozwala nie tylko uporządkować prace analityczne, ale także uporządkować cały proces szukania rozwiązania. Każdemu, kto ma ochotę się rozwijać, polecam osiągnięcia myślicieli z obszaru filozofii nauki (patrz artykuł Wiedza a nauka i prawda). […] Tu także inny artykuł zaczynający się od słów:

Analiza systemowa, ogólna teoria systemów, świat to chaos czy złożoność? Biznes i jego otoczenie to złożoność, która dla wielu jest chaosem. (Źródło: Wszystkie drogi prowadzą do Rzymu | | Jarosław Żeliński IT-Consulting).

Uogólniając, warto się oswoić z filozofią analityczną i logiką, bo na niej między innymi oparte są fundamenty notacji takich jak UML, BPMN i nie tylko. Warto nauczyć się zapisywać zdobytą wiedzę o analizowanej organizacji z pomocą schematów blokowych i formalnych notacji, zgodnie z maksymą:

jeżeli czegoś nie potrafisz poprawnie narysować to znaczy, że jeszcze tego nie rozumiesz…

Ważna rzecz: gdy tylko to możliwe, czytać cudze dokumenty i analizować ich wady, w szczególności wszystko to, co okazało się niejasne i niejednoznaczne, to co było przyczyną porażki projektu, bo to te wady dokumentów, które należy usuwać w swojej własnej pracy.

I podstawa: nie być konformistą (ponad 3/4 projektów IT to wtopy a nie sukcesy…. wiec większość nie ma racji). Na tej Stronie (mój blog) znajdziecie recenzje wybranych książek, które polecam.

Czy są gotowe zestawy dokumentów, w oparciu o które można napisać specyfikację

Osobiście nie spotkałem takich i nie polecam ich szukania… Każda analizowana firma jest inna, więc każda analiza będzie miała inną wynikową treść. Można mówić o ramie, czyli kluczowych etapach analizy i tym samym o kluczowych rozdziałach specyfikacji:

1. wprowadzenie czyli cel biznesowy podmiotu analizowanego, także to (opis) jak sprawdzimy, że firma ten cel (po zakończeniu projektu) zrealizowała (tu przydaje się notacja BMM),
2. model działania podmiotu analizowanego pokazuje w jaki sposób organizacja działa, należy przede wszystkim zbadać i pokazać jak powstają dokumenty i ich treść, co powoduje (jakie fakty), że te dokumenty w ogóle powstają (tu modele procesów biznesowych, szablony dokumentów, słowniki i reguły biznesowe, głównie notacje BPMN, SBVR, tu ewentualnie UML jako narzędzie dokumentowania aktualnego stanu IT w organizacji),
3. projekt rozwiązania problemu, czyli opis stanu docelowego: jakie rozwiązanie (zmiany organizacyjne, nowe systemy IT, inne) należy wdrożyć by zrealizować cel biznesowy; to etap napisania wymagań na nowe rozwiązanie, jeżeli zapada decyzja że będzie to nowe lub aktualizowane oprogramowanie, piszemy wymagania:
   1. jeżeli ryzyko projektu jest niezbyt duże, opisać je tradycyjnie czyli cechami oczekiwanymi, np. zgodnie z normą IEEE Std 830-1998,
   2. jeżeli okaże się, że opis metodą cech zewnętrznych jest zbyt ryzykowny (czyli w zasadzie każdy nietrywialny system), idziemy w MDA/MDE (model PIM w UML, INCOSE/SysML) opisywane na tym blogu nie raz bo w tym się specjalizuję.

Dokumentacja w procesach prowadzonych zwinnie – czy jest potrzebna, jak dokładna powinna być, kiedy powinna być tworzona, kiedy się przydaje?

O zwinności w IT zapisano tony papieru :).

Każdy kto poszedł do sklepu i wrócił z niego bez ważnych sprawunków, wie po co piszemy listy zakupów: nie mamy aż tak dobrej pamięci. Generalnie brak dokumentacji ma takie same skutki jak jej nadmiar: bardzo szkodzi w projekcie i podnosi koszty. Dokumentacja to komunikacja między uczestnikami projektu i samemu z sobą (przeczytajcie swoje dokumenty z przed kilku miesięcy, a nawet tylko z przed tygodni).

Co do zasady, dokumentować należy wszystkie decyzje, w szczególności architektoniczne. Decyzjami są w szczególności zatwierdzone wymagania (klient zdecydował, że chce TO mieć).  Podstawowym celem tworzenia dokumentacji jest potrzeba wiedzy o tym CO ZOSTAŁO ZAMÓWIONE oraz CO ZOSTAŁO ZROBIONE i DLACZEGO TAK.

Pod pojęciem zwinności rozumiem takie prowadzenie projektu i dokumentacji, by nie powstawały treści (dokumenty) zbędne, czyli przede wszystkim nie powinny powstawać opisy zawierające:

1. szybko dezaktualizujące się detale, projekt trwa w czasie a czas to zmiana otoczenia rynkowego czyli także  wymagań,
2. zapisy treści spotkań, zupełnie wystarczy pierwotny dokument wymagań (patrz wyżej produkt analizy) i bieżące aktualizowanie go na podstawie zgłoszonych żądanych zmian lub pytań o kolejne szczegóły.

Tu podam przykład: dokumentacja wymagań dla Senatu miała w momencie rozpoczęcia prac developera (wymagania na dzień ogłoszenie przetargu) 35 stron (wartość oferty na wykonanie tego co w niej opisano to ok. 250 tys.). Plan komunikacji wyglądał tak, że odpowiedzią na każde pytanie developera była odpowiedź (nadzór autorski) w postaci zaktualizowanej w odpowiednim miejscu dokumentacji z początku projektu. Developer musiał z góry deklarować wszystkie swoje bieżące techniczne decyzje (koncepcja wdrożenia), które były także nanoszone w dokumentacji.  W efekcie w dniu zakończenia tworzenia oprogramowania istniała kompletna jego dokumentacja: miała 84 strony. Reszta to detale w kodzie i dokument Koncepcji Wdrożenia czyli to co opracował i wykonał developer (ja się na to tylko powołuję).

Nie jest też prawdą, że dokumentacja jest (liniowo?) tym większa im większa aplikacja ma powstać. Im większa aplikacja tym dłużej w czasie trwa jej powstawanie, dlatego im większy projekt tym dokumentacja jest bardziej polityką budowy systemu, jego architektura i koncepcja, niż detalicznym projektem, co oczywiście wcale nie znaczy, że jej powstanie nie będzie kosztowniejsze: do przeanalizowania jest duża organizacja i duży projekt.

Jakość tworzonej dokumentacji (temat omawiamy przy okazji wspomnienia o instrukcji wyłączenia kontroli składni w EA)

O jakości dokumentacji decyduje w 100% jej zrozumiałość (w tym także więc jednoznaczność), spójność  i kompletność (nie mylić z jakością samego opisanego w niej projektu). To zaś oznacza, że wszelkie odstępstwa od standardów to pogorszenie jakości. Ideałem jest taki dokument, który został w całości przeczytany przez jego adresata developera (a więc niezbyt obszerny) i nie wymaga kontaktu z jego autorem to by zrozumieć jego treść i jednoznacznie ją zinterpretować. W przetargach miernikiem jakości jest np. liczba pytań oferentów do treści wymagań a w każdym projekcie ilość wprowadzanych zmian (ale nie rozszerzeń). Tak więc odstępstwa od zasad stosowania użytych notacji, stosowanie slangu w treści, stosowanie niestandardowych i zamkniętych  licencjami metod i notacji, brak słownika pojęć, to wszystko powoduje, że dokumentacja staje się sama z siebie problemem w projekcie.

Jedną z najgorszych rzeczy jest niestety łamanie zasad użytej notacji, a nie raz po prostu nieumiejętne (niezamierzone) jej stosowanie. W jednej z książek na temat użycia UML, jej autor słusznie zauważa we wstępie:

Wielu autorów dokumentów projektowych używa UML (BPMN, itp.) nie jak sformalizowanych systemów notacyjnych a jak biblioteki symboli w Power Poincie, jest to tragedia tych autorów.

(o walidacji w EA niedawno pisałem więcej)

Narzędzia wspomagające pracę analityka – visual paradigm (VP) a enterprise architect (EA), co lepsze, jak dokonać wyboru

To klasyczne pytanie o narzędzia. Pierwsza rzecz: narzędzie, które znasz jest zawsze lepsze od tego, którego nie znasz. Warto też wiedzieć, że na rynku pracy standardem de facto jest nadal EA (wystarczy spojrzeć na ogłoszenia o pracę). Od tego momentu będzie subiektywnie ;):

• EA jest relatywnie tani, dość powszechny, ale też mało ergonomiczny i bardzo pracochłonny, nadal dominuje w korporacjach i dużych firmach  IT bo tu liczy się dostępność kompetencji na rynku pracy zaś koszt  projektów spada na drugi plan bo klienci i tak zapłacą za “mendejsy”.
• VP jest droższy od EA, zaczyna jednak dominować w małych firmach o małej rotacji pracowników i u freelancerów, bo jest ergonomiczny, ma bardzo dobre wsparcie dla sformalizowanych notacji a także dla metodyk zwinnych, ma wersje polską (w tym polską kontrolę ortografii), pozwala tworzyć w locie dokumentację bez potrzeby korzystania z pakietów biurowych i programowania SQL; VP daje bardzo wysokiej jakości usługi w chmurze jakimi są serwer wersjonujący projekty i narzędzia do zdalnej komunikacji z klientami (1 GB na projekty w cenie licencji).

Ja używam VP od 2005 r., na warsztatach zaś nadal regularnie miewam uczestników z EA, zawsze mają jakieś z tworzeniem diagramów w zgodzie z notacją i metodami takim jak śladowanie i zawsze tworzenie diagramów trwa dłużej niż i mnie z użyciem VP.

Od prawie 10 lat nie używam pakietów biurowych (edytorów tekstów i arkuszy kalkulacyjnych) do tworzenia dokumentacji (wyżej wskazana dokumentacja dla Senatu  powstała w 100% z użyciem VP).

Sami więc musicie wybrać…

Czy “logowanie” jest przypadkiem użycia ( )

Logowanie nie jest powodem zakupu oprogramowania, logowanie to jedna z możliwych implementacji wymagania ?tylko autoryzowany użytkownik może korzystać z aplikacji?, co nie przeszkadza większości amatorów używania tych diagramów (w tym autorów książek) potraktowania logowania jako przypadku użycia aplikacji. Dobrym testem sensu umieszczania takich rzeczy na diagramach przypadków użycia jest zadawanie sobie pytania: ?czy kupił byś tę aplikację tylko dla tego jednego przypadku użycia??

Tyle cytat z mojego artykułu Ile przypadków użycia? | | Jarosław Żeliński IT-Consulting (polecam lekturę całego).  Wiele nieporozumień tworzy książka Alistaira Cockburn’a Stosowanie przypadków użycia: jego książka nie ma nic wspólnego z UML. Jeżeli powyższe jednak pytanie o przypadki użycia dotyczy diagramów w UML, to przypadek użycia jest tam definiowany jako “usługa dla aktora świadczona przez system, dla której to usługi został on kupiony/stworzony”.  Mam świadomość ile jest tego rodzaju przykładów (logowanie jako przypadek użycia) w sieci, ale warto tu nie być konformistą…

Przypomnę, że także opcja w menu każdego oprogramowania [Exit/Zakończ/Wyloguj] jest klikana, ma dialog [czy jesteś pewien TAK/NIE] i mimo to nie jest przypadkiem użycia tego oprogramowania.

Jaka jest różnica między analitykiem biznesowym a analitykiem systemowym

Na to pytanie nie ma odpowiedzi, bo te pojęcia nie mają ścisłej definicji. Zwyczajowo się przyjmuje w wielu firmach podział na:

• analityk biznesowy zbiera i porządkuje wymagania (elicitation),
• analityk systemowy coś projektuje w UML (system description).

Patrząc na wcześniejsze moje odpowiedzi:

• często analitykiem biznesowym nazywa się osobę tworzącą SRS (System Requirements Specification, specyfikacja wymagań), najczęściej zgodnie z IEEE Std 830-1998,
• często analitykiem systemowych nazywa się architekta oprogramowania (co nie do końca jest zgodne z prawdą i faktami),
• ale w MDA powstają modele: CIM, PIM PSM, analityk biznesowy (patrz także IIBA) powinien być autorem modeli CIM i PIM, developer (wykonawca) wykona implementację i być może wykona także model PSM; rola tak zwanego analityk systemowego zanika, nie tylko w literaturze, jako sztuczna rola pomiędzy tymi dwiema (analityk projektant i developer czyli wykonawca).

Cel biznesowy w dokumentacji – co zrobić, gdy: brak jasno sprecyzowanego celu biznesowego; cele biznesowe wykluczają się nawzajem; cele biznesowe wykraczają poza obszar projektu

To będzie krótka odpowiedź: nie realizować takiego projektu. Wiem, że pracodawcy analityka może się taka odpowiedź nie spodobać, ale podtrzymuję swoje zdanie. Jeżeli nie uda się zamawiającego namówić na usunięcie tej wady projektu, uczciwy analityk się wycofa… W przeciwnym wypadku ktoś w końcu powie głośno: dostaliśmy dokładnie to co chcieliśmy i zupełnie nie to czego potrzebujemy.

Czy rejestrować funkcjonalności, których realizacja została wykluczona podczas specyfikowania

Najlepszą znaną mi metodą zarządzania wymaganiami jest zarządzanie ich statusami (w tym status: poza zakresem projektu), więc nie usuwamy ich ze specyfikacji. To pomaga później przypomnieć innym, że wymaganie było i dlaczego zostało usunięte z zakresu. Czasem jest ono przesuwane do kolejnej nowszej wersji. Dobrą praktyką jest zapisanie dla każdego wymagania: właściciela czyli osoby zgłaszającego wymaganie po stronie zamawiającego, szacowanego kosztu implementacji, bieżącego statusu.

Czy zawsze warto analizować organizacje i otoczenie biznesowe projektu

Zawsze :). Bez tego nie wiemy nic o sense i celu projektu 🙂  … Tu uwaga: dobry analityk to nie najemnik, który jak mu zapłacą zrobi każda głupotę… patrz wyżej pytanie o realizację projektu mającego źle sformułowane cele.

Jak rejestrować uprawnienia użytkowników – macierz uprawnień?

Obecnie macierz to chyba (poza rzadkimi wyjątkami) najgorsza metoda. Zarówno z powodu zmienności uprawnień w trakcie życia organizacji jak i nie raz ogromnych rozmiarów takiej macierzy. Uprawnienia dokumentujemy i zarządzamy nimi w aplikacjach z użyciem reguł biznesowych. To pozwala by aplikacja sama dynamicznie tym uprawnieniami zarządzała, np. “prawa dostępu do treści dokumentu ma tylko osoba prowadząca sprawę związaną z tym dokumentem oraz jej bezpośredni przełożony”. Zmiany kadrowe, przekazanie sprawy innej osobie, nie przełożą się na jakąkolwiek pracochłonność związaną z prawami dostępu do dokumentu, administrator systemu jest wyłączony z ingerowania te w prawa co dodatkowo podnosi bezpieczeństwo całości systemu.

Jedną, z chyba najgorszych, metod dokumentowania uprawnień jest diagram przypadków użycia, który dzięki temu natychmiast staje się nie raz monstrualnie rozbudowany (czyli nieczytelny).

Minęło 8 lat

Od czasu gdy w 2018 brałem udział w warsztacie “Stary analityk odpowiada na pytania młodych”. Teraz ogłosiłem, że jednak napisze książkę dla początkujących. od jednej osoby dostałem ciekawy zestaw pytań pod hasłem “Pierwsze 90 dni analityka”

Co robić w pierwszym tygodniu?

Zapoznać się z tym co i dla kogo robi firma (lub dział) oraz jakimi metodami pracuje. Kluczem jest dokładne zrozumienie swojej roli i odpowiedzialności, tego “co i kto ma mi dostarczyć oraz co i komu ja mam dostarczyć”. Zakładam, że od pierwszego dnia wiadomo kto jest przełożonym 😉

Jak budować relację z devami?

Co do zasady za te relacje odpowiada menedżer całości bo to on ustala (powinien) zasady i metody komunikacji. Niezależnie od tego kluczem jest ustalenia tego jakie i w jakiej postaci i formie (narzędziu) deweloper (zespół) chce dostawać informacje.

Jak zdobyć zaufanie PO?

Zaufanie to wzajemny szacunek dla swoich ról projektach. PO także powinien umieć jawnie określić czego oczekuje, bo to nie powinno być “proszenie o zaufanie”, to powinna być wzajemna umowa.

Jak nie zostać „sekretarką projektu”?

Wymagać szanowania zawartych umów na to kto i jakie produkty oraz dla kogo, tworzy w projekcie 😉

Podstawy SQL (select, where, join itd)

To nie ma nic wspólnego z analizami i projektowaniem! To implementacja. Na etapie projektu powstają jedynie (powinny) szablony formularzy, dokumentów, komunikatów (API) i ich walidacje. SQL to jedna z wielu, nie jedyna, metod utrwalania danych. .

Czy analityk musi umieć programować?

Nie jest to jego rola ale powinien rozumieć na czym kodowanie polega. Poniższa tabelka (pochodzi ze strony pewnej firmy rekrutacyjnej z USA) podział na role, poza biznesem są dwie: projektant i koder:

Jak negocjować zakres?

Jeżeli to pytanie o zakres projektu to służy do tego diagram przypadków użycia (UC) oraz wykonane specyfikacje każdego z nich: szablon ekranu i scenariusz dialogu aktor-system.

Co zrobić, gdy developer mówi „to się nie da”?

Poprosić o wyjaśnienie 😉

Jak reagować, gdy biznes zmienia zdanie?

Informować o tym sponsora projektu wskazując wpływ tej zmiany na koszty całego projektu.

Kiedy powiedzieć „nie”?

Zawsze gdy ktoś oczekuje tego czego nie obiecaliśmy 🙂

BPMN (AS-IS / TO-BE)

Co do zasady analiza to audyt czyli stan as-is. Jeżeli jest oczekiwanie rekomendowania zmian, to wtedy powstaje model to-be. Pamiętajmy, że raczej nie jest to “cały nowy model” (czyli nowa firma) a jedynie te obszary, w których proponowane są zmiany i początkowo jest to “proof of concept” czy te zmiany mają sens. To-be to rzadkie kiedy więcej niż 10% całości modelu procesów firmy.

Diagram sekwencji

To test tego czy model model komponentów i klas są poprawne. Po wykazaniu poprawności te diagramy są wyjaśnieniem (dokumentacją) tego jak system działa.

Diagram kontekstu systemu

Nie ma takiego bytu w UML, kontekst i zakres pokazujemy na diagramie przypadków użycia bo do tego właśnie powstał.

Prosty model danych (relacje 1:N)

Nie robimy tego w projektach obiektowo-komponentowo (mikro-serwisy) zorientowanych z powodów opisanych wyżej (SQL). Relacyjne modele danych do drugi etap projektowania w metodach strukturalnych (diagramy DFD i ER). “Na przykład: diagram dla systemu rejestracji wizyt lekarskich”. W projektach obiektowych z zasady nie ma diagramów ER, mogą się pojawić modele ORM ale to praca dewelopera a nie analityka.

Często na rozmowach o prace

Co to jest API?

API to skrót Application programming Interface. To bardzo ogólne pojęcie bo API to KAZDY zestaw operacji interfejsu. Przedmiotem projektowania jest to jakie to polecenia i jakie procedury one uruchamiają. Docelowo w projekcie każda operacja API to diagram sekwencji (lub czasami aktywności).

Co to request/response?

To metoda definiowania pojedynczej operacji API:

• Request: aplikacja kliencka wysyła żądanie (wywołuje operację API) do punktu końcowego, np. innej aplikacji (serwera)
  
• Processing: API odbiera żądanie i wykonuje wywołaną operację (określony scenariusz)
  
• Response: odpowiedź jaką zwraca operacja API, zazwyczaj w standardowym formacie, takim jak JSON lub XML.

Co to JSON?

Jest to skrót (ang.) JavaScript Object Notation. Jest to tekstowy format wymiany danych, niezależny od języka programowania, czytelny take dla ludzi. Opiera się na parach etkieta-wartość, służy do przesyłania danych. Stanowi często stosowaną “lżejszą” alternatywę dla formatu XML ale ale nie zastępuje go.

Jak czytać Swagger?

Polecam narzędzia, ja używam Visual Paradigm. Ja kończę na modelowaniu, detale to już raczej poziom kodowania.

Co to integracja synchroniczna vs asynchroniczna?

Generalnie dotyczy to dialogu między systemami i diagramów sekwencji. Ogólnie rzecz biorąc: w komunikacji synchronicznej “pytający czeka na odpowiedź” a w komunikacji asynchronicznej nie czeka (czytaj więcej).

Co to walidacja danych?

Jest to sprawdzenie ich poprawności. Dokumentujemy to w postaci zbudowania formularza oraz powiązanego z nim zestawu reguł poprawności. Co do zasady mamy dwa poziomy walidacji:

1. poprawność pól (typy danych: czy nazwisko to poprawne nazwisko, czy data to poprawna data, itp.)
2. poprawność treści formularza: data płatności nie poprzedza daty faktury, nazwisko czytelnika jest nazwiskiem aktywnego studenta, itp.)

Różnica między wymaganiem biznesowym, funkcjonalnym i niefunkcjonalnym

1. wymaganie biznesowe to potrzeby użytkownika: system pozwala na wygenerowanie faktury zgodnej z prawem, system automatycznie monituje przeterminowane płatności, system pozwala sprawdzić które zamówienia zostały zafakturowane, itp.
2. wymagania funkcjonalne to cechy systemy zapewniające realizację potrzeb biznesowych, np. potrzeba “system pozwala sprawdzić które zamówienia zostały zafakturowane” wymaga opracowania formularzy: “na każdej fakturze jest numer powiązanego z nią zamówienia”. Z zasady są definiowane jako przypadki użycia UML i ich specyfikacje.
3. wymagania nie-funckjonalne to cechy jakościowe systemu takie jak czas odpowiedzi, czas dostępności, środowisko.

Tu ważna uwaga: np. sklep internetowy z książkami pozwala sprawdzić kto napisał książkę gdy znamy jej tytuł, jednak sklep ten nie po powstał. Innymi słowy: sklep internetowy generalnie służy biznesowi do sprzedaży książek przez internet i po to powstał, ale realizuje także potrzebę jaką jest zdobywanie informacji o autorach książek. Ta potrzeba mogła być wymaganiem, albo nie.

Co to są acceptance criteria?

Kryteria odbioru. Sa to mierzalne cechy (warunki) systemu jakie musi on spełniać, by uznać że jest zgodny z wymaganiami. Wiele metodyk zakłada, że wymagania na system powinny być formułowane w firmie takich kryteriów (wymagania powinny być testem, lub powinny być testowalne).

Czym jest Definition of Done?

Jest to mierzalne kryterium ukończenia określonego etapu pracy.

Dlaczego wymagania muszą być testowalne?

Bo bez tego nie mozna określić czy zostały spełnione 🙂

Jak prowadzić warsztat?

Nie wiem, od wielu lat ich nie robię. Coraz więcej autorów zwraca uwagę, że to nieskuteczna metoda analizy i należy się skupić na analizie dokumentów biznesowych: Christian Ruf. (2015). Towards an Artifact-Oriented Requirements Engineering Model for Developing Successful Products, Services, and Systems: Identification of Model Requirements. Bled eConference, 14.

Jak zadawać pytania otwarte?

Pytania otwarte to pytania dając pytanemu pełną swobodę co do treści odpowiedzi. Często zaczynają się od słów: jak, co, dlaczego, po co, kiedy, kto, w jaki sposób.

Jak radzić sobie z konfliktem interesów?

Nie ma takiego sposobu, konfliktu interesu należy unikać.

Co zrobić, gdy stakeholder mówi: „To oczywiste”?

Ignorować i pytać. Ja wtedy mówię: “Proszę mi to wyjaśnić, chciał bym uniknąć nieporozumienia”.

Czym różni się potrzeba biznesowa od rozwiązania? Dlaczego „Zróbmy aplikację mobilną” nie jest wymaganiem?

Bo jest decyzją projektową.

Co się stanie, jeśli wdrożymy rozwiązanie bez analizy procesu?

Jest bardzo prawdopodobne, że poniesiemy porażkę na etapie wdrożenia. Wtedy pojawiają sie tak zwane “trupy w szafie”, czyli wymagania odkrywane w trakcie próby korzystania z systemu.

Jak rozpoznać, że stakeholder nie mówi o prawdziwym problemie?”?

Zacząć modelować…wtedy pojawiają sie “dyndające w powietrzu strzałki” czyli niespójność modelu.

Brief Analityka Projektanta IT

1 plik(i) 5.90 MB

Pobierz

Grubsze sprawy

Jak poprawnie (najlepiej krok po kroku) identyfikować przypadki użycia? Innymi słowy skąd biorą się przypadki użycia? Z procesów biznesowych? Co jeśli tworzymy aplikację nie dla biznesu a użytkową (mapy, gry, monitorowanie zdrowia, monitorowanie aktywności fizycznej)? Jak wtedy identyfikować przypadki użycia?

Przypadki użycia “znikąd sie nie biorą”, przypadek użycia aplikacji to określona usługa jaka ta aplikacja świadczy. Przypadek użycia to z definicji (UML) odpowiedz na pytanie: “Do czego system służy i komu”. Nie należy tego mylić z “celem użytkownika”, bo Internetowy Sklep z Książkami co do zasady służy do sprzedaży książek, ale wielu ludzi używa go np. do tego by np. sprawdzić kto jest autorem określonej książki ale nie jest to “przypadek użycia sklepu internetowego”. Przypadki Użycia to “główne menu systemu”, to propozycja projektanta w odpowiedzi na potrzeby biznesowe. To jak ten system będzie te potrzeby realizował to proponowane scenariusze dialogu aktor-system, a ich integralną częścią są szablony ekranów/formularzy/dokumentów. Po uzyskaniu zgody sponsora, można rozpocząć projektowanie realizacji tych usług (nie mylić z implementacją/kodowaniem) czyli robimy Proof of Concept pomysłu. Ja udowodnimy, że rozumiemy jak realizować te usługi ma sens zlecanie ich implementacji (kodowanie). Patrz V-model (A. Cockburn, ten co napisał książkę Stosowanie Przypadków Użycia.) poniżej. Kluczem identyfikacji PU jest identyfikacja aktorów (człowiek, inny system, urządzenie)

Większość postów dotyczy projektów, w których rozwiązanie budowane jest od zera – jak pracować jako analityk-projektant w zespołach, gdzie trzeba zmodyfikować istniejący komponent, dodać nowy, zintegrować dodatkowy system, często nie ma dokumentacji obecnego rozwiązania

To częste pytanie i wbrew pozorom odpowiedź jest prosta: należy opracować (odtworzyć) model istniejącego oprogramowania i potem zarządzać zmianą (jak udokumentować istniejące oprogramowanie). Po drugie posty dotyczą analiz i projektowania wymaganej logiki, to czy będzie to aplikacja dedykowana jest konsekwencją tego czy na rynku jest czy nie aplikacja spełanijąca nasze wymagania. Dlatego początek projektu z zasady nie determinuje tego czy ma powstać aplikacja dedykowana czy nie.

Brakuje mi na rynku czegoś takiego jak modelowanie w danym programie wraz z pokazaniem jak powinna wyglądać struktura takiego pliku. Nigdzie tego nie ma. Zakładając, że zaczynam od analizy biznesowej z wykorzystaniem UML idąc do analizy systemowej z wykorzystaniem BPMN+UML

I to jest bardzo dobry pomysł, dlatego publikuję portfolio gdzie jest możliwość zakupienia pliku źródłowego Visual Paradigm.

Spis wiedzy elementarnej tj. lista pojęć które trzeba przyswoić tak, jak tabliczkę mnożenia lub lista książek/ innych źródeł wiedzy które owe podstawy opisują- takie fundamenty które ukształtowały Pana karierę lub są według Pana absolutnym wymogiem dla bycia dobrym w “te klocki”.

Opis procesu projektowania krok po kroku: od analizy przedsiębiorstwa – po zbieranie wymagań – aż po projekt systemu. Co więcej rozdział o wzorcach projektowania integracji między systemami oraz same oprogramowania oraz porównanie ich ze sobą kiedy ma sens ich użycie, a kiedy nie.

Taki opis już powstał:

Brief Analityka Projektanta IT

1 plik(i) 5.90 MB

Pobierz

Chętnie zobaczyłbym rozdział pokazujący flow SDLC i spójność różnego rodzaju specyfikacji z uwzględnieniem ról. Użytkownika interesuje działający program w środowisku uruchomieniowym. Ekspertów biznesowych interesuje spełnianie wymagań funkcjonalnych. Analityk/projektant/architekt definiuje model/design. Następnie ten design jest specyfikowany, danym językiem dla narzędzi budujących kompilatorów. Jak zapewnić spójność w całym przepływie? Analitykowi model i wymagania się zgadzają. Kod się kompiluje. Na koniec albo defekty, albo nie dowieziona wartość biznesowa. Jak mitygować ryzyko rozproszenia odpowiedzialności za dostarczenie poprawnie działającego rozwiązania? Jak zarządzać pętla zwrotną od eksperta biznesowego/użytkownika?

Każdy przykład na stronie Fast Start! to taka pętla, a jej motorem jest Żywa Dokumentacja. Jedynym sposobem walki z ryzykiem rozproszenia odpowiedzialności jest niedopuszczanie tego tego rozproszenia, dlatego od dekad prawnicy przypominają o roli i prawo jakimi są “autorskie prawa osobiste’, ktore po prostu należy egzekwować.

Chciałbym zobaczyć proces analizy konkretnego przypadku (a najlepiej kilku), z przykładami diagramów i informacjami dlaczego zastosowano takie rozwiązanie

Prosze bardzo: https://it-consulting.pl/zamow/program-referencyjny-twoja-architektura-biznesowa/#portfolio

i w jakich sytuacjach byłyby inne (np. kiedy mikroserwisy, a kiedy monolit)

Z zasady nie stosujemy monolitów w biznesie z uwagi na jego zmienność. Z zasady (prawie zawsze) stosujemy monolity w budowie środowiska, bo ono z zasady przez lata prawie sie nie zmienia. Dlatego monolitem może być system operacyjny i nie powinien nim być żaden system ERP.

Mamy zamodelowane wszystko, wszystko sie spina z wymaganiami, wszystko działa…ale…patrzymy na to co zamówił biznes i nie pasuje to nam. Np biznes nie zwrócił uwagi, że coś można walidować, albo blokować – to my czujemy intuicyjnie, że coś moze działać lepiej – mamy proponować, czy robimy wg wytycznych bo inaczej projekt rośnie (zakres).

Jak to wygląda gdy pracujemy w firmie na etacie a gdy jestesmy z zewnatrz?

Jeżeli te modele i wymagania zostały wprost odwzorowane jako diagramy, bez żadnej walidacji biznesowej to efekty są właśnie takie: “mamy to co chcieliśmy a nie to czego potrzebujemy”. Co do zasady: biznes zgłasza potrzeby bo biznes nie jest projektantem systemu. Tworzenie systemów pod dyktando biznesu to klasyczny błąd i przyczyna porażek w IT. Samolotów nie projektują ani piloci ani pasażerowie. Pamiętajmy, że wymagania biznesowe to potrzeby a nie projekt. Po drugie łącznikiem między potrzeba biznesową a deweloperem nie są wymagania a projekt (design) i projektant (designer).

Analityk-projektant na etacie vs. zewnętrzny. Kluczem sukcesu projektu jest niezależność analityk-projektanta i podległość wyłącznie sponsorowi projektu. Zapewnienie tego gdy jest on etatowym pracownikiem (struktura podległości i nieformalne uzależnienia) jest znacznie trudniejsze.

W swoich postach piszesz że programiści to koderzy, ale kluczowe w pracy jest to żeby Ci koderzy zrozumieli jak zaprogramować. Jako analityk biznesowy przygotowujemy diagramy, algorytmy ale kluczowe jest to żeby upewnić się że “koder” rozumie co ma zrobić. W pana postach nie widziałem aby mówił Pan wgl o komunikacji z zespołem developerskim. Ciekawi mnie czy w pana pracy wręcza Pan dokumentację zespołowi i się żegna czy jest Pan wsparciem w zrozumieniu dokumentacji. Oczywiście może Pan powiedziec że w modelach nie ma dwuznaczności niemniej jednak nie każdy “koder” rozumie każdy niuans każdej strzałki w każdym diagramie, a ta przenosi jakąś zakodowana informacje.

Bardzo dobre pytanie!

1. pojęcie “koder” ma tradycje w literaturze anglojęzycznej od czasów pierwszych komputerów:

• inżynier analizuje problem i projektuje rozwiązanie: to struktury danych, procedury, algorytmy i ich architektura wyrażone schematami blokowymi i wzorami matematycznymi.
• technik-koder odwzorowuje je z pomocą określonego języka programowania i uruchamiania w komputerze.
  (poniżej tabelka pewnej firmy rekrutacyjnej, odwzorowująca ten podział)

2. Droga do tego by “upewnić się że “koder” rozumie co ma zrobić” to metody obiektowe i UML: takie pojęcia jak klasa, atrybut, operacja, metoda (procedura, algorytm) oraz wywołanie operacji, to w 100% jednoznaczny język, to pojęcia wspólne i dla UML i każdego obiektowego języka kodowania.

3. Paradoksalnie o komunikacji piszę nie mało: projekt w UML oraz feedback dewelopera to ta komunikacja

4. “Ciekawi mnie czy w pana pracy wręcza Pan dokumentację zespołowi i się żegna czy jest Pan wsparciem w zrozumieniu dokumentacji. ” Co do zasady jestem do samego końca do dyspozycji dewelopera i sponsora (biznes), to sie nazywa “nadzór autorski”, ja dodatkowo udzielam gwarancji na treść dokumentów jakie przekazuję. Prowadzę on-line “żywą dokumentację” to znaczy, ze na każde pytanie dewelopera (kodera) odpowiadam kolejnym akapitem lub rozdziałem specyfikacji w efekcie ostatniego dnia projektu na stole leży dokumentacja tego co powstało. I tak cały czas.

Jeżeli taki projektant sobie znika z projektu to jest to dramat 🙂

Jeżeli deweloper/koder nie rozumie czegoś na diagramie UML to:
– albo diagram (projektant|) jest zły
– albo koder nie rozumie istoty obiektowego języka programowania którego używa

I Ty zadaj pytanie…

Powyżej pytania zadane mi na spotkaniach i Linked In. Zachęcam do zadawania kolejnych pytań i dyskusji pod tym artykułem, szczególnie tych którzy nie znaleźli tu odpowiedzi na nurtujące ich pytania, a chcą poznać moje zdanie ;), i pamiętaj: zanim zadasz pytanie, upewnij się, że chcesz poznać odpowiedź ;).

Nie chcesz czekać na odpowiedź? Masz pytania ale to specyfika Twojej firmy i nie może jej upubliczniać? Wybierz Mentoring.