Ten artykuł to zanonimizowana korespondencja, na często pojawiający sie temat: zakres pracy analityka.
O co chodzi
Dzień dobry, piszę z prośbą/pytaniem czy byłby Pan w stanie polecić książkę albo inny zasób z ćwiczeniami UML oraz BPMN?
Jest z tym problem bo jest mało literatury i często są to płatne publikacje naukowe. Powód jest dość prozaiczny: 1. komercyjne projektty są chronione tajemnica przedsiębiorstwa, 2. napisanie takich ćwiczeń i przykładów jest pracochłonne i mało kto to robi. Mogę polecić swoją książkę i mojego bloga ;), na blogu pod wpisami zawsze podaje wykorzystaną i zalecaną literaturę. Nie wiem z czym ma Pan problem: sama notacja jako taka, specyficzne konstrukcje w modelach, inne? Proponuję zacząć od wyszukiwarki na mojej stronie i zadawania pytań pod artykułami. Bardzo prawdopodobne, że dostanie bezpłatne wsparcie ode mnie tą metodą, a potem się zobaczy, na bazie takich pytań byłoby mi też łatwo jakąś konkretną literaturę polecić.
Dzień dobry, w ramach wolnego czasu chciałem po prostu móc przerabiać różne scenariusze do modelowania zamiast wymyślać z głowy. Zwłaszcza, że niektórych diagramów w praktyce nie wykorzystuję, a nie chciałbym aby moja wiedza pozostała tylko teoretyczna. Przy okazji czy Pana zdaniem analityk w ramach wykonywania analizy systemowej powinien projektować i dokumentować komunikację w systemie w kontekście tego jak powinien wyglądać dany Webservice: dane, definicja metod get/post oraz czy powinien modelować komunikację na diagramie sekwencji pokazując kiedy i jaki endpoint jest wołany z danego web-servisu oraz czy powinien projektować procesy serwisów z pokazaniem kiedy są 200, 300, 400, 500ki? Czy analityk powinien pokazać jaki zakres danych powinien być dostarczony przez system w ramach takiego a takiego procesu, a to już architekt/solution designer projektuje komunikację? Innymi słowy do jakiego momentu leży zakres odpowiedzialności analityka, a kiedy już powinien działać architekt?
Proponuję zapoznać się z tym przykładem to typowy zakres pracy (poniżej), pamiętajmy, że w każdej inżynierii to co nazywamy “analityk biznesowy/systemowy”, to tak na prawdę architekt rozwiązania (ale nie developer). Więc w zakresie ma: zrozumieć co ma powstać, opisać, opracować model (mechanizm) działania tego rozwiązania. https://it-consulting.pl/2020/12/11/analiza-biznesowa-od-zlecenia-do-kompletnego-projektu-technicznego-z-uzyciem-narzedzia-case/Inżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka – Jarosław Żeliński IT-Consultingit-consulting.pl ? 4 min read
To co nazywamy tu “oczekiwanym/zalecanym zakresem pracy analityka” opisałem tu: https://it-consulting.pl/analiza-systemowa-organizacji-i-analiza-systemu-informacyjnego/
Odnośnie “Opisać, opracować model (mechanizm) działania tego rozwiązania” Właśnie kwestia na jaki poziom szczegółowości powinien schodzić analityk. Oczywiście co firma to inna praktyka, jednak zakładam że mamy jakiś typowy zakres.
Poziom szczegółowości na tym etapie to tak zwany model PIM (OMG.org/MDA).
Generalnie projekt rozwiązania to jego architektura: komponenty, ich role w systemie, i opis tego jak zrealizowana będzie każda usługa (czyli każdy use case) czyli komunikacja między komponentami. podział na analityka i architekta w IT jest sztuczny i szkodliwy, wielu ludzi to już napisało.
Każda inżynieria: budownictwo, samoloty, sprzęt AGD itp. to: – biznesowy model pokazujący komu i do czego potrzebny będzie; dom, samolot, lodówka. To opisuje “biznes” (to są wymagania biznesowa) – wymagania biznesowe należy sformalizować do postaci procesów biznesowych (jak ludzie skorzystają z tych produktów i kiedy) – mając tę formalizację tworzymy zakres systemu jako model Use Case (umawiamy się jakie usługi i do czego będzie miał system, w zasadzie jest to specyfikacja głównego menu aplikacji) – projektowanie mechanizmu realizacji każdego Use Case 9architektura i komunikacja).
Detale robi deweloper, np. webserwisy warto rozumieć ale na tym etapie opisujemy na diagramie sekwencji, operowanie kodami RESTfull API nie jest konieczne. W kwestii projektowania zorientowanego na Use Case polecam to: Ivar Jacobson, Ian Spence, & Kurt Bittner. (2014, lipiec 21). Use-Case 2.0 ebook. Ivar Jacobson International. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook Kurt Bittner. (2011). Use-Case 2.0: Scaling up, scaling out, scaling in for agile projects. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
W kwestii projektowania architektury polecam to (którakolwiek): Miller, J., & Wirfs-Brock, R. (1999). How Can a Subsystem Be Both a Package and a Classifier? (s. 753). https://doi.org/10.1007/3-540-46852-8_41 Wirfs-Brock, R., & McKean, A. (2006). Object Design: Roles, Responsibilities and Collaborations,. 88. Wirfs-Brock, R., & McKean, A. (2009). Object design: Roles, responsibilities, and collaborations. Addison-Wesley. Wirfs-Brock, R., McKean, A., & Kowalczyk, P. (2006). Projektowanie obiektowe: Role, odpowiedzialność i współpraca. Helion.
W kwestii całościowego podejścia do systemów polecam to: Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: The systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml
Generalnie zadał Pan dość popularne pytanie.
Rozumiem, dziękuję. Przyznam, że jak rozmawiałem z znajomymi analitykami i nawet innymi znajomymi z IT, którzy pracują w innych rolach, raczej potwierdzają, że projektowanie API to już zakres odpowiedzialności architekta/developera. Innymi słowy projektowania rozwiązania na takim poziomie szczegółowości jak na załączonym diagramie, to już zdecydowanie kwestia architekta:
Częściej, stwierdzam na podstawie dyskusji z innymi, analityk jeśli już to projektuje rozwiązanie, z użyciem diagramu sekwencji na bardziej ogólnym poziomie, jak na kolejnej załączonej grafice:
I właśnie o te detale chodzi. Głownie pytanie czy analityk czy architekt powinien projektować API w zakresie: <nazwa mikroserwisu> API Metoda 1 typu GET/POST, zakres danych, odpowiedzi pozytywne negatywne Metoda 2 typu GET/POST, zakres danych, odpowiedzi pozytywne negatywne Metoda 3 ….
Jak pisałem wyżej, większość kolegów i koleżanek po fachu jednak podziela pogląd, że jeśli chodzi te detale to już kwestia architekta.
Drugi diagram jest niestety niemalże bezwartościowy jako opis, bo nie zawiera informacji o tym jakie dane są przekazywane, innymi słowy samo stwierdzenie “sprzedaj”, jest bezwartościowe bez opisu struktury faktury, samo stwierdzenie “autoryzuj” bez definicji: co to oznacza, jakie dane należy podać i jakich oczekujemy w odpowiedzi, jest niestety żadnym projektem, bo jakakolwiek niespójność danych odkryta na dopiero etapie developmentu bardzo dużo kosztuje.
Nie musimy pisać detali REST typu “Komunikat 200”, ale opis API bez struktur XML/JSON jest po prostu nic nie wart… stanowi co najwyżej luźny pomysł, bez gwarancji że ma sens… Tak więc logika (mechanizm działania) systemu nie musi być projektem implementacji w określonej technologii (mamy inne API niż REST) ale musi być kompletnym spójnym modelem PIM (Platform Independent Model)
W kwestii projektowania zorentowanego na Use Case polecam to:
Ivar Jacobson, Ian Spence, & Kurt Bittner. (2014, lipiec 21). Use-Case 2.0 ebook. Ivar Jacobson International. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
Kurt Bittner. (2011). Use-Case 2.0: Scaling up, scaling out, scaling in for agile projects. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
W kwestii projektowania architektury polecam to (którakolwiek):
Miller, J., & Wirfs-Brock, R. (1999). How Can a Subsystem Be Both a Package and a Classifier? (s. 753). https://doi.org/10.1007/3-540-46852-8_41
Wirfs-Brock, R., & McKean, A. (2006). Object Design: Roles, Responsibilities and Collaborations,. 88.
Wirfs-Brock, R., & McKean, A. (2009). Object design: Roles, responsibilities, and collaborations. Addison-Wesley.
Wirfs-Brock, R., McKean, A., & Kowalczyk, P. (2006). Projektowanie obiektowe: Role, odpowiedzialność i współpraca. Helion.
w kwestii całościowego podejścia do systemów polecam to:
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: The systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml
Nie ma analityków biznesowych itp.
Tak więc nie ma analityków biznesowych itp. Jest osoba, która analizuje problem i projektuje jego rozwiązanie, oraz jest osoba lub zespół, która to rozwiązanie wytworzy i wdroży.
Poniżej definicje dwóch podstawowych ról w inżynierii, tu inżynierii oprogramowania:
