Ten arty­kuł to zano­ni­mi­zo­wa­na kore­spon­den­cja, na czę­sto poja­wia­ją­cy sie temat: zakres pra­cy analityka.

O co chodzi

Dzień dobry, piszę z prośbą/pytaniem czy był­by Pan w sta­nie pole­cić książ­kę albo inny zasób z ćwi­cze­nia­mi UML oraz BPMN? 

Jest z tym pro­blem bo jest mało lite­ra­tu­ry i czę­sto są to płat­ne publi­ka­cje nauko­we. Powód jest dość pro­za­icz­ny: 1. komer­cyj­ne pro­jekt­ty są chro­nio­ne tajem­ni­ca przed­się­bior­stwa, 2. napi­sa­nie takich ćwi­czeń i przy­kła­dów jest pra­co­chłon­ne i mało kto to robi. Mogę pole­cić swo­ją książ­kę i moje­go blo­ga ;), na blo­gu pod wpi­sa­mi zawsze poda­je wyko­rzy­sta­ną i zale­ca­ną lite­ra­tu­rę. Nie wiem z czym ma Pan pro­blem: sama nota­cja jako taka, spe­cy­ficz­ne kon­struk­cje w mode­lach, inne? Proponuję zacząć od wyszu­ki­war­ki na mojej stro­nie i zada­wa­nia pytań pod arty­ku­ła­mi. Bardzo praw­do­po­dob­ne, że dosta­nie bez­płat­ne wspar­cie ode mnie tą meto­dą, a potem się zoba­czy, na bazie takich pytań było­by mi też łatwo jakąś kon­kret­ną lite­ra­tu­rę polecić.

Dzień dobry, w ramach wol­ne­go cza­su chcia­łem po pro­stu móc prze­ra­biać róż­ne sce­na­riu­sze do mode­lo­wa­nia zamiast wymy­ślać z gło­wy. Zwłaszcza, że nie­któ­rych dia­gra­mów w prak­ty­ce nie wyko­rzy­stu­ję, a nie chciał­bym aby moja wie­dza pozo­sta­ła tyl­ko teo­re­tycz­na. Przy oka­zji czy Pana zda­niem ana­li­tyk w ramach wyko­ny­wa­nia ana­li­zy sys­te­mo­wej powi­nien pro­jek­to­wać i doku­men­to­wać komu­ni­ka­cję w sys­te­mie w kon­tek­ście tego jak powi­nien wyglą­dać dany Webservice: dane, defi­ni­cja metod get/post oraz czy powi­nien mode­lo­wać komu­ni­ka­cję na dia­gra­mie sekwen­cji poka­zu­jąc kie­dy i jaki end­po­int jest woła­ny z dane­go web-servi­su oraz czy powi­nien pro­jek­to­wać pro­ce­sy ser­wi­sów z poka­za­niem kie­dy są 200, 300, 400, 500ki? Czy ana­li­tyk powi­nien poka­zać jaki zakres danych powi­nien być dostar­czo­ny przez sys­tem w ramach takie­go a takie­go pro­ce­su, a to już architekt/solution desi­gner pro­jek­tu­je komu­ni­ka­cję? Innymi sło­wy do jakie­go momen­tu leży zakres odpo­wie­dzial­no­ści ana­li­ty­ka, a kie­dy już powi­nien dzia­łać architekt?

Proponuję zapo­znać się z tym przy­kła­dem to typo­wy zakres pra­cy (poni­żej), pamię­taj­my, że w każ­dej inży­nie­rii to co nazy­wa­my ​„ana­li­tyk biznesowy/systemowy”, to tak na praw­dę archi­tekt roz­wią­za­nia (ale nie deve­lo­per). Więc w zakre­sie ma: zro­zu­mieć co ma powstać, opi­sać, opra­co­wać model (mecha­nizm) dzia­ła­nia tego roz­wią­za­nia. https://​it​-con​sul​ting​.pl/​2​0​2​0​/​1​2​/​1​1​/​a​n​a​l​i​z​a​-​b​i​z​n​e​s​o​w​a​-​o​d​-​z​l​e​c​e​n​i​a​-​d​o​-​k​o​m​p​l​e​t​n​e​g​o​-​p​r​o​j​e​k​t​u​-​t​e​c​h​n​i​c​z​n​e​g​o​-​z​-​u​z​y​c​i​e​m​-​n​a​r​z​e​d​z​i​a​-​c​a​se/Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE – przy­kła­do­wy pro­jekt Biblioteka – Jarosław Żeliński IT​-Consultingit​-con​sul​ting​.pl ? 4 min read

To co nazy­wa­my tu ​„oczekiwanym/zalecanym zakre­sem pra­cy ana­li­ty­ka” opi­sa­łem tu: https://​it​-con​sul​ting​.pl/​a​n​a​l​i​z​a​-​s​y​s​t​e​m​o​w​a​-​o​r​g​a​n​i​z​a​c​j​i​-​i​-​a​n​a​l​i​z​a​-​s​y​s​t​e​m​u​-​i​n​f​o​r​m​a​c​y​j​n​e​go/

Odnośnie ​„Opisać, opra­co­wać model (mecha­nizm) dzia­ła­nia tego roz­wią­za­nia” Właśnie kwe­stia na jaki poziom szcze­gó­ło­wo­ści powi­nien scho­dzić ana­li­tyk. Oczywiście co fir­ma to inna prak­ty­ka, jed­nak zakła­dam że mamy jakiś typo­wy zakres.

Poziom szcze­gó­ło­wo­ści na tym eta­pie to tak zwa­ny model PIM (OMG​.org/​MDA).

Generalnie pro­jekt roz­wią­za­nia to jego archi­tek­tu­ra: kom­po­nen­ty, ich role w sys­te­mie, i opis tego jak zre­ali­zo­wa­na będzie każ­da usłu­ga (czy­li każ­dy use case) czy­li komu­ni­ka­cja mię­dzy kom­po­nen­ta­mi. podział na ana­li­ty­ka i archi­tek­ta w IT jest sztucz­ny i szko­dli­wy, wie­lu ludzi to już napisało. 

Każda inży­nie­ria: budow­nic­two, samo­lo­ty, sprzęt AGD itp. to: – biz­ne­so­wy model poka­zu­ją­cy komu i do cze­go potrzeb­ny będzie; dom, samo­lot, lodów­ka. To opi­su­je ​„biz­nes” (to są wyma­ga­nia biz­ne­so­wa) – wyma­ga­nia biz­ne­so­we nale­ży sfor­ma­li­zo­wać do posta­ci pro­ce­sów biz­ne­so­wych (jak ludzie sko­rzy­sta­ją z tych pro­duk­tów i kie­dy) – mając tę for­ma­li­za­cję two­rzy­my zakres sys­te­mu jako model Use Case (uma­wia­my się jakie usłu­gi i do cze­go będzie miał sys­tem, w zasa­dzie jest to spe­cy­fi­ka­cja głów­ne­go menu apli­ka­cji) – pro­jek­to­wa­nie mecha­ni­zmu reali­za­cji każ­de­go Use Case 9architektura i komunikacja). 

Detale robi dewe­lo­per, np. webser­wi­sy war­to rozu­mieć ale na tym eta­pie opi­su­je­my na dia­gra­mie sekwen­cji, ope­ro­wa­nie koda­mi RESTfull API nie jest koniecz­ne. W kwe­stii pro­jek­to­wa­nia zorien­to­wa­ne­go na Use Case pole­cam to: Ivar Jacobson, Ian Spence, & Kurt Bittner. (2014, lipiec 21). Use-Case 2.0 ebo­ok. Ivar Jacobson International. https://​www​.ivar​ja​cob​son​.com/​p​u​b​l​i​c​a​t​i​o​n​s​/​w​h​i​t​e​-​p​a​p​e​r​s​/​u​s​e​-​c​a​s​e​-​e​b​ook Kurt Bittner. (2011). Use-Case 2.0: Scaling up, sca­ling out, sca­ling in for agi­le pro­jects. https://​www​.ivar​ja​cob​son​.com/​p​u​b​l​i​c​a​t​i​o​n​s​/​w​h​i​t​e​-​p​a​p​e​r​s​/​u​s​e​-​c​a​s​e​-​e​b​ook

W kwe­stii pro­jek­to­wa­nia archi­tek­tu­ry pole­cam to (któ­ra­kol­wiek): Miller, J., & Wirfs-Brock, R. (1999). How Can a Subsystem Be Both a Package and a Classifier? (s. 753). https://​doi​.org/​1​0​.​1​0​0​7/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, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley. Wirfs-Brock, R., McKean, A., & Kowalczyk, P. (2006). Projektowanie obiek­to­we: Role, odpo­wie­dzial­ność i współ­pra­ca. Helion. 

W kwe­stii cało­ścio­we­go podej­ścia do sys­te­mów pole­cam to: Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: The sys­tems mode­ling lan­gu­age (Third edi­tion). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml

Generalnie zadał Pan dość popu­lar­ne pytanie.

Rozumiem, dzię­ku­ję. Przyznam, że jak roz­ma­wia­łem z zna­jo­my­mi ana­li­ty­ka­mi i nawet inny­mi zna­jo­my­mi z IT, któ­rzy pra­cu­ją w innych rolach, raczej potwier­dza­ją, że pro­jek­to­wa­nie API to już zakres odpo­wie­dzial­no­ści architekta/developera. Innymi sło­wy pro­jek­to­wa­nia roz­wią­za­nia na takim pozio­mie szcze­gó­ło­wo­ści jak na załą­czo­nym dia­gra­mie, to już zde­cy­do­wa­nie kwe­stia architekta:

Częściej, stwier­dzam na pod­sta­wie dys­ku­sji z inny­mi, ana­li­tyk jeśli już to pro­jek­tu­je roz­wią­za­nie, z uży­ciem dia­gra­mu sekwen­cji na bar­dziej ogól­nym pozio­mie, jak na kolej­nej załą­czo­nej grafice:

I wła­śnie o te deta­le cho­dzi. Głownie pyta­nie czy ana­li­tyk czy archi­tekt powi­nien pro­jek­to­wać API w zakre­sie: <nazwa mikro­ser­wi­su> API Metoda 1 typu GET/POST, zakres danych, odpo­wie­dzi pozy­tyw­ne nega­tyw­ne Metoda 2 typu GET/POST, zakres danych, odpo­wie­dzi pozy­tyw­ne nega­tyw­ne Metoda 3 .…

Jak pisa­łem wyżej, więk­szość kole­gów i kole­ża­nek po fachu jed­nak podzie­la pogląd, że jeśli cho­dzi te deta­le to już kwe­stia architekta.

Drugi dia­gram jest nie­ste­ty nie­mal­że bez­war­to­ścio­wy jako opis, bo nie zawie­ra infor­ma­cji o tym jakie dane są prze­ka­zy­wa­ne, inny­mi sło­wy samo stwier­dze­nie ​„sprze­daj”, jest bez­war­to­ścio­we bez opi­su struk­tu­ry fak­tu­ry, samo stwier­dze­nie ​„auto­ry­zuj” bez defi­ni­cji: co to ozna­cza, jakie dane nale­ży podać i jakich ocze­ku­je­my w odpo­wie­dzi, jest nie­ste­ty żad­nym pro­jek­tem, bo jaka­kol­wiek nie­spój­ność danych odkry­ta na dopie­ro eta­pie deve­lop­men­tu bar­dzo dużo kosztuje. 

Nie musi­my pisać deta­li REST typu ​„Komunikat 200”, ale opis API bez struk­tur XML/JSON jest po pro­stu nic nie wart… sta­no­wi co naj­wy­żej luź­ny pomysł, bez gwa­ran­cji że ma sens… Tak więc logi­ka (mecha­nizm dzia­ła­nia) sys­te­mu nie musi być pro­jek­tem imple­men­ta­cji w okre­ślo­nej tech­no­lo­gii (mamy inne API niż REST) ale musi być kom­plet­nym spój­nym mode­lem PIM (Platform Independent Model)

W kwe­stii pro­jek­to­wa­nia zoren­to­wa­ne­go na Use Case pole­cam to:

Ivar Jacobson, Ian Spence, & Kurt Bittner. (2014, lipiec 21). Use-Case 2.0 ebo­ok. Ivar Jacobson International. https://​www​.ivar​ja​cob​son​.com/​p​u​b​l​i​c​a​t​i​o​n​s​/​w​h​i​t​e​-​p​a​p​e​r​s​/​u​s​e​-​c​a​s​e​-​e​b​ook
Kurt Bittner. (2011). Use-Case 2.0: Scaling up, sca­ling out, sca­ling in for agi­le pro­jects. https://​www​.ivar​ja​cob​son​.com/​p​u​b​l​i​c​a​t​i​o​n​s​/​w​h​i​t​e​-​p​a​p​e​r​s​/​u​s​e​-​c​a​s​e​-​e​b​ook

W kwe­stii pro­jek­to­wa­nia archi­tek­tu­ry pole­cam to (któ­ra­kol­wiek):

Miller, J., & Wirfs-Brock, R. (1999). How Can a Subsystem Be Both a Package and a Classifier? (s. 753). https://​doi​.org/​1​0​.​1​0​0​7/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, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley.
Wirfs-Brock, R., McKean, A., & Kowalczyk, P. (2006). Projektowanie obiek­to­we: Role, odpo­wie­dzial­ność i współ­pra­ca. Helion.

w kwe­stii cało­ścio­we­go podej­ścia do sys­te­mów pole­cam to:

Friedenthal, S., Moore, A., & Steiner, R. (2015). A prac­ti­cal guide to SysML: The sys­tems mode­ling lan­gu­age (Third edi­tion). 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 ana­li­ty­ków biz­ne­so­wych itp. Jest oso­ba, któ­ra ana­li­zu­je pro­blem i pro­jek­tu­je jego roz­wią­za­nie, oraz jest oso­ba lub zespół, któ­ra to roz­wią­za­nie wytwo­rzy i wdroży. 

Poniżej defi­ni­cje dwóch pod­sta­wo­wych ról w inży­nie­rii, tu inży­nie­rii oprogramowania:

Źródła