Wyniki wyszukiwania dla zapytania „BMM”

BMM

Business Motivation Model, nota­cja opu­bli­ko­wa­na przez orga­ni­za­cję Object Management Group (https://​www​.omg​.org/​s​p​e​c​/​B​MM/), dostar­cza model poję­cio­wy do ana­li­zy, two­rze­nia, doku­men­to­wa­nia biz­ne­spla­nu i metod zarzą­dza­nia oraz sys­tem sym­bo­li pozwa­la­ją­cy two­rzyć dia­gra­my mode­lu­ją­ce ele­men­ty misji i wizji, stra­te­gii i celów biz­ne­so­wych orga­ni­za­cji, nota­cja BMM odwo­łu­je do nota­cji BPMN i SBVR a tak­że do mode­li struk­tur orga­ni­za­cyj­nych, poni­żej szkie­let systemu:

Diagram Przypadków Użycia UML

Dodaj komentarz

Wstęp

Jest to dia­gram, któ­ry na rów­ni z Diagramem Klas, budzi bar­dzo czę­sto ogrom­ne pro­ble­my inter­pre­ta­cyj­ne (patrz: Diagram klas…). Bardzo wie­lu auto­rów przy­pi­su­je temu dia­gra­mo­wi role, któ­rych on nie peł­ni, a nie raz pre­zen­to­wa­ne w sie­ci i lite­ra­tu­rze przy­kła­dy są nie­po­praw­ne. Znakomita więk­szość auto­rów tych dia­gra­mów uży­wa ich jako ​„zbio­ru moż­li­wych klik­nięć” co jest cał­ko­wi­tym nie­zro­zu­mie­niem celu uży­cia i idei tego dia­gra­mu. Nawet jeże­li ktoś potrze­bu­je takiej mapy kli­ka­nia, to są do tego lep­szych narzę­dzia i meto­dy (przy­kład: Mapa ekra­nów apli­ka­cji – pod­sta­wa dobre­go UX/UI design). Tworzenie nie­zgod­nych z nota­cją dia­gra­mów przy­pad­ków uży­cia po pro­stu psu­je struk­tu­rę pro­jek­tu w narzę­dziach CASE, czy­niąc ją prak­tycz­nie bez­u­ży­tecz­ną w pro­jek­to­wa­nia archi­tek­tu­ry systemu. 

Najpierw opi­szę krót­ko dia­gram przy­pad­ków uży­cia posłu­gu­jąc sie cyta­ta­mi z ory­gi­nal­nej spe­cy­fi­ka­cji. Później opi­szę typo­we błędy. 

Czym jest Diagram Przypadków Użycia

Kluczowe są tu wyja­śnie­nia wstę­pu do roz­dzia­łu UseCases Specyfikacji UML :

18 UseCases
18.1 Use Cases
18.1.1 Summary
UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase’s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors.
[…]
18.1.3 Semantics
18.1.3.1 Use Cases and Actors
A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the sub­ject. A UseCase is a kind of BehavioredClassifier that repre­sents a dec­la­ra­tion of a set of offe­red Behaviors. Each UseCase spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal structure.

Powyższe wytłusz­cze­nia zebra­łem poni­żej, uwa­gi ozna­czo­ne „[…]” są moje:

  1. Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły na rzecz i na żąda­nie Aktora].
  2. Każdy Przypadek Użycia repre­zen­tu­je okre­ślo­ny cel (powód), dla któ­re­go System jest projektowany. 
  3. Przypadek Użycia jest rodza­jem kla­sy­fi­ka­to­ra beha­wio­ral­ne­go, któ­ry repre­zen­tu­je dekla­ra­cję zbio­ru ofe­ro­wa­nych zacho­wań. [to zna­czy, że gru­pu­je okre­ślo­ny kon­tek­sto­wo powią­za­ny zbiór zacho­wań, są to alter­na­tyw­ne sce­na­riu­sze tego same­go przy­pad­ku użycia].
  4. Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] sys­te­mu bez odwo­ły­wa­nia się do jego wewnętrz­nej struktury. (!)

Są to pryn­cy­pia budo­wy tych diagramów.

Związki między Przypadkami Użycia

Extend

Specyfikacja UML:

An Extend is a rela­tion­ship from an exten­ding UseCase (the exten­sion) to an exten­ded UseCase (the extendedCase) that spe­ci­fies how and when the beha­vior defi­ned in the exten­ding UseCase can be inser­ted into the beha­vior defi­ned in the exten­ded UseCase. The exten­sion takes pla­ce at one or more spe­ci­fic exten­sion points defi­ned in the exten­ded UseCase. Extend is inten­ded to be used when the­re is some addi­tio­nal beha­vior that sho­uld be added, possi­bly con­di­tio­nal­ly, to the beha­vior defi­ned in one or more UseCases.

Związku «extend» moż­na użyć do poka­za­nia, że pew­ne ele­men­ty zacho­wa­nia Systemu reali­zo­wa­ne są warun­ko­wo. Te dodat­ko­we zacho­wa­nia są jed­nak z zasa­dy czę­ścią bazo­we­go Przypadku Użycia.

Autorzy spe­cy­fi­ka­cji UML jasno piszą, że: ​„Szczegółowy spo­sób okre­śla­nia poło­że­nia punk­tu roz­sze­rzeń jest celo­wo nie­okre­ślo­ny. Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp. […] Zazwyczaj, przy­pa­dek uży­cia z ExtensionPoints skła­da się z zesta­wu drob­no­ziar­ni­stych opi­sów frag­men­tów zacho­wa­nia (sce­na­riu­sze), któ­re są naj­czę­ściej wyko­ny­wa­ne w pew­nej sekwen­cji. Taka seg­men­to­wa struk­tu­ra tek­stu opi­su dane­go przy­pad­ku uży­cia pozwa­la na roz­sze­rze­nie pier­wot­ne­go opi­su zacho­wa­nia przez dołą­cza­nie dodat­ko­wych opi­sów, frag­men­tów zacho­wa­nia, w odpo­wied­nich punk­tach wsta­wia­ne pomię­dzy pier­wot­ne frag­men­ty (punk­ty roz­sze­rzeń). Tak więc, roz­sze­rze­nie UseCase skła­da się zwy­kle z jed­ne­go lub wię­cej opi­sów frag­men­tów zacho­wa­nia, któ­re mają być wsta­wio­ne w odpo­wied­nie miej­sca roz­sze­rza­ne­go przy­pad­ku uży­cia. Rozszerzenia są więc spe­cy­fi­ka­cją wszyst­kich róż­nych punk­tów roz­sze­rzeń w danym przy­pad­ku uży­cia, w któ­rych moż­na umie­ścić dodat­ko­we zachowania.”

Innymi sło­wy, for­mal­nie moż­na na Diagramie Przypadków Użycia poka­zać, to że sce­na­riusz przy­pad­ku uży­cia jest podzie­lo­ny na frag­men­ty, któ­re są wyko­ny­wa­ne warun­ko­wo. Jest to jed­nak mode­lo­wa­nie sce­na­riu­sza zawie­ra­ją­ce­go instruk­cje ​„if … then”. Tu przy­po­mnę więc klu­czo­wą zasa­dę, zapi­sa­ną w spe­cy­fi­ka­cji UML: ​„Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Dlatego wie­lu auto­rów zwra­ca uwa­gę na pew­ne, ​‚takie jak ta, nie­kon­se­kwen­cje w specyfikacji. 

Include

Specyfikacja UML:

The Include rela­tion­ship is inten­ded to be used when the­re are com­mon parts of the beha­vior of two or more UseCases. This com­mon part is then extrac­ted to a sepa­ra­te UseCase, to be inc­lu­ded by all the base UseCases having this part in com­mon. As the pri­ma­ry use of the Include rela­tion­ship is for reu­se of com­mon parts, what is left in a base UseCase is usu­al­ly not com­ple­te in itself but depen­dent on the inc­lu­ded parts to be meaning­ful. This is reflec­ted in the direc­tion of the rela­tion­ship, indi­ca­ting that the base UseCase depends on the addi­tion but not vice versa.

Innymi sło­wy: jeże­li dwa Przypadki Użycia mają pew­ne wspól­ne frag­men­ty zacho­wa­nia, moż­na taki frag­ment ​„wyjąć przed nawias”, ten frag­ment jest na dia­gra­mie repre­zen­to­wa­ny tak­że jako Przypadek Użycia, jed­nak jest to nie­sa­mo­dziel­ny frag­ment, sta­no­wią­cy część wspól­ną co naj­mniej dwóch PU bazo­wych i on sam z sie­bie nie repre­zen­tu­je samo­dziel­ne­go zacho­wa­nia. Ten wspól­ny, wyłą­czo­ny frag­ment, łączy­my z PU bazo­wy­mi związ­kiem «inc­lu­de».

Tak więc związ­ki «inc­lu­de» i «extend» owszem nadal są w spe­cy­fi­ka­cji UML, jed­nak ​„Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp.” i ktoś może chcieć taki tek­sto­wy for­mat zobra­zo­wać na Diagramie. 

Konsekwencje

Diagram Przypadków uży­cia ma rodo­wód w meto­dy­ce struk­tu­ral­nej (sto­so­wa­nie instruk­cji ​„go to” i ​„sub­ro­uti­ne” w pro­gra­mo­wa­niu struk­tu­ral­nym). Związki «extend» i «inc­lu­de» mają wła­śnie taki rodo­wód i nadal są w nota­cji UML, gdyż Diagram Przypadków Użycia jest nadal popu­lar­nym narzę­dziem w meto­dach struk­tu­ral­nych. Jest też nie­kon­se­kwen­cją spe­cy­fi­ka­cji UML, co widać w jej tre­ści, gdzie na począt­ku roz­dzia­łu auto­rzy spe­cy­fi­ka­cji UML zwra­ca­ją jed­nak uwa­gę, że ​„Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Więc sto­so­wa­nie powyż­szych związ­ków jest relik­tem metod struk­tu­ral­nych, i nie nale­ży ich sto­so­wać w pro­jek­tach zorien­to­wa­nych obiek­to­wo, tym bar­dziej, że jest to łama­nie pod­sta­wo­wej zasa­dy para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Autorzy spe­cy­fi­ka­cji nota­cji UML, takim oto przy­kła­dem pod­su­mo­wu­ją roz­dział 18. Przypadki Użycia:

Jak widać celem pro­jek­to­wa­nia ban­ko­ma­tu są: Wypłata, Wpłata, Przelew, a tak­że: Rejestrowanie ban­ko­ma­tu (w sie­ci) i Udostępnianie listy trans­ak­cji. Detale tych dzia­łań i kolej­ność ich reali­za­cji nie są przed­mio­tem tego mode­lu, nie ma tu związ­ków «inc­lu­de» ani «extend», mimo, że np. trzy klu­czo­we ope­ra­cje wyma­ga­ją uży­cia kar­ty płat­ni­czej i kodu PIN (owszem, wspól­na część, ale są to jed­nak deta­le sce­na­riu­szy a nie osob­ne PU).

Traktując więc PU zgod­nie z jego pod­sta­wo­wą, przy­to­czo­ną powy­żej defi­ni­cją, jako: ​„okre­ślo­ny cel (powód), dla któ­re­go System jest pro­jek­to­wa­ny”, uzna­je­my, że celem apli­ka­cji biz­ne­so­wej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że ​„Drukujemy doku­ment”, ​„szu­ka­my fak­tu­ry” czy ​„wpro­wa­dza­my NIP kon­tra­hen­ta”. Pokazanie dru­ko­wa­nia jako wyłą­czo­nej czę­ści wspól­nej, lub roz­sze­rze­nia, PU Faktura i Zamówienie (sto­su­jąc zwią­zek «inc­lu­de» lub «extend»), czy też wydzie­la­nie na dia­gra­mie PU ​„Wybór klien­ta z listy kon­tra­hen­tów”, to pro­jek­to­wa­nie archi­tek­tu­ry i dro­ga do klę­ski tego dia­gra­mu. To, że kom­po­nent reali­zu­ją­cy dru­ko­wa­nie będzie osob­nym ele­men­tem archi­tek­tu­ry tego sys­te­mu zapew­ne jest praw­dą, ale Diagram PU, jak już wie­my, to nie jest model archi­tek­tu­ry sys­te­mu. Nie jest to tak­że spe­cy­fi­ka­cja pro­ce­su biznesowego.

Obiektowo-zorientowane modelowanie systemu

W arty­ku­le Use Case 2.0 opi­sy­wa­łem kon­cep­cję obiek­to­we­go podej­ścia w pro­jek­to­wa­niu zorien­to­wa­nym na Przypadki Użycia, opra­co­wa­ną przez jed­ne­go z współ­twór­ców UML: Ivara Jacobsona . W arty­ku­le Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych opi­sa­łem pro­jek­to­wa­nie opro­gra­mo­wa­nia opar­te na obiek­to­wym para­dyg­ma­cie i wzor­cach pro­jek­to­wych takich jak mikro­ser­wi­sy. Cytowałem mię­dzy inny­mi ten diagram:

Po pra­wej stro­nie powyż­sze­go widzi­my archi­tek­tu­rę zorien­to­wa­ną na mikro­ser­wi­sy. Jest to typo­we i zna­ne od lat kom­po­nen­to­we podej­ście z her­me­ty­za­cją kom­po­nen­tów, reali­zu­ją­cych usłu­gi apli­ka­cji . Bloki [MS] (micro­se­rvi­ces) to nic inne­go jak kom­po­nen­ty reali­zu­ją­ce Przypadki Użycia tego sys­te­mu. Każdy PU ma wła­sną imple­men­ta­cję (i bazę danych, dane [DB] tak­że nie są współ­dzie­lo­ne mię­dzy przy­pad­ka­mi uży­cia). Komponent [UI] to zagre­go­wa­ne na jed­nym ekra­nie wywo­ła­nia usług, czy­li głów­ne menu sys­te­mu. Tak więc Diagram Przypadków Użycia, to model tego głów­ne­go menu sys­te­mu, a nie model imple­men­ta­cji usług (nie archi­tek­tu­ra kodu i nie pro­ces biznesowy).

Podsumowanie

Na poniż­szym dia­gra­mie po lewej stro­nie, poka­za­no for­mal­nie popraw­ny dia­gram przy­pad­ków uży­cia. Z per­spek­ty­wy pro­jek­to­wa­nia zorien­to­wa­ne­go na kom­po­nen­ty, oraz zacho­wa­nia zasa­dy mówią­cej, że ten dia­gram nie słu­ży do mode­lo­wa­nia wewnętrz­nej archi­tek­tu­ry sys­te­mu, popraw­na pro­jek­to­wo jest wer­sja poka­za­na po pra­wej stronie:

Warto też wie­dzieć, że w kon­se­kwen­cji powyż­sze­go, łącze­nie Aktora z wydzie­lo­ny­mi, nie­sa­mo­dziel­ny­mi, opi­sa­mi zacho­wań repre­zen­to­wa­ny­mi przez przy­pad­ki uży­cia 4 i 5, jest pozba­wio­ne logi­ki (podob­nie jak tyl­ko jeden PU połą­czo­ny związ­kiem «inc­lu­de»).

Więc jak i gdzie poka­zać owe sce­na­riu­sze PU? Osobno na dia­gra­mach aktyw­no­ści (role kom­po­nen­tów) lub na dia­gra­mach sekwen­cji (wywo­ły­wa­ne ope­ra­cje inter­fej­sów). (Patrz arty­kuł: Diagram aktyw­no­ści – kie­dy).

Powyższa for­ma (dia­gram po pra­wej stro­nie) ma tak­że prak­tycz­ną zale­tę: Zamawiający zro­zu­mie ten dia­gram. Diagram o po lewej, jest już prak­tycz­ną utra­tą komu­ni­ka­cji z Zamawiającym, bo mało któ­ry z nich stu­diu­je spe­cy­fi­ka­cję UML. Specyfikacja po lewej pro­wa­dzi tak­że do ogrom­ne­go zawy­ża­nia osza­co­wa­nia wycen, gdyż mia­ry opar­te na tak zwa­nych punk­tach funk­cyj­nych, trak­tu­ją każ­dy PU jako samo­dziel­ną, kom­plet­ną jed­ną jed­nost­kę kosztową. 

A co może­my zna­leźć w sie­ci? Poniżej kil­ka przy­kła­dów wraz ze źró­dła­mi, ich oce­nę pozo­sta­wię czytelnikom. 

przykład 1

Major elements of business use case UML diagram.

(w nota­cji UML nie ma i nigdy nie było poję­cia ​„biz­ne­so­wy przy­pa­dek uży­cia”, to poję­cie jest relik­tem meto­dy RUP, Rational Unified Process, z cza­sów gdy nie było nota­cji BPMN i BMM).

przykład 2

Major elements of UML use case diagram.

przykład 3

enter link description here
(https://​stac​ko​ver​flow​.com/​q​u​e​s​t​i​o​n​s​/​2​8​6​1​4​1​4​3​/​u​s​e​-​c​a​s​e​-​d​i​a​g​r​a​m​-​w​i​t​h​-​m​u​l​t​i​p​l​e​-​s​y​s​t​ems)

przykład 4

(źr.: Podstawy mode­lo­wa­nia w języ­ku UML, dr hab. Bożena Woźna-Szcześniak, prof. UJD, Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie, http://​www​.wozna​.org/​s​t​u​d​e​n​t​s​/​2​018 – 2019/uml/UML03.pdf)

Dla porów­na­nia do pobra­nia: Biblioteka

przykład 5

(źr. https://​www​.alt​ko​ma​ka​de​mia​.pl/​b​a​z​a​-​w​i​e​d​z​y​/​q​n​a​/​d​i​s​c​u​s​s​i​o​n​/​8​8​4​8​/​z​a​l​e​z​n​o​s​c​i​-​z​a​w​i​e​r​a​n​i​a​-​p​r​z​y​p​a​d​k​o​w​-​u​z​y​c​i​a​-​w​-​d​i​a​g​r​a​m​i​e​/p1)

przykład 6

(źr.: Projektowanie Systemów Komputerowych, Laboratoria/Projekty, Krzysztof Regulski, AGH, WIMiIP, DIAGRAM PRZYPADKÓW UŻYCIA – USE CASE MODEL, https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf)

___

Na koniec pole­cam też arty­kuł: Ile przy­pad­ków uży­cia?

Źródła

D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
Ivar Jacobson, Ian Spence, & Kurt Bittner. (2014, July 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
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/

Komunikacja czyli wiadomości ode mnie

Profil subskrybenta

Jeżeli chcesz dowie­dzieć sie wię­cej o publi­ko­wa­nej tu tre­ści poni­żej znaj­dziesz opis. 

Artykuły czyli o czym tu piszę

Publikacje powsta­ją nie­re­gu­lar­nie: są to jeden, cza­sa­mi dwa tek­sty każ­de­go mie­sią­ca. Zawierają opi­sy wybra­nych pozy­cji lite­ra­tu­ro­wych, opi­sy pro­ble­mów jakie napo­ty­kam w toku audy­tów u klien­tów i ich roz­wią­za­nia, oraz efek­ty prac badawczych.

Publikuje tak­że infor­ma­cje o pla­no­wa­nych kon­fe­ren­cjach, w któ­rych bio­rę udział jako prelegent. 

Poza tema­ta­mi z obsza­ru ana­li­zy biz­ne­so­wej i inży­nie­rii sys­te­mów, oma­wiam tak­że pro­ble­my takie jak pra­wo autor­skie, ochro­na war­to­ści inte­lek­tu­al­nych i know-how, bo są to klu­czo­we cechy doku­men­tów sta­no­wią­cych wyni­ki ana­liz i pro­jek­to­wa­nia, uży­wa­ne czę­sto jako załącz­ni­ki do umów na dostar­cze­nie oprogramowania. 

Tematy, które można subskrybować

Audyty i Modele Biznesowe (CIM)

CIM to Computation Independent Model (mode­lo­wa­nie orga­ni­za­cji). W tej czę­ści uka­zu­ją arty­ku­ły z obsza­ru mode­lo­wa­nia biz­ne­so­we­go, sze­ro­ko poję­tej ana­li­zy biz­ne­so­wej i mode­lo­wa­nia pro­ce­sów biz­ne­so­wych, doku­men­to­wa­nia logi­ki biz­ne­so­wej. Pojawiają się wzmian­ki o nota­cjach BPMN, SBVR, BMM. 

Inżynieria i Modelowanie Systemów (PIM)

PIM to Platform Independent Model (mode­lo­wa­nie sys­te­mów) W tej czę­ści uka­zu­ją się arty­ku­ły z zakre­su inży­nie­rii sys­te­mów, opro­gra­mo­wa­nia, na pozio­mie ana­li­zy i doku­men­to­wa­nia logi­ki dzie­dzi­no­wej sys­te­mów oraz pro­jek­to­wa­nia ich archi­tek­tu­ry. Pojawiają się wzmian­ki o nota­cjach UML i SysML. 

„Jestem dostawcą oprogramowania”

To lista na któ­rą wysy­łam zapy­ta­nia ofer­to­we od moich klien­tów, tak zwa­ne RFI, wysy­łam gdy klient zle­ci mi prze­pro­wa­dze­nie tego pro­ce­su (na eta­pie RFI mój klient bar­dzo czę­sto nie chce wyja­wiać sie­bie jako nabyw­cy). Drugim eta­pem jest zawsze roze­sła­nie kon­kret­nych zapy­tań RFP do firm wybra­nych spo­śród ofe­ren­tów RFI (zapo­znaj się z przy­kła­da­mi).

Jeżeli repre­zen­tu­jesz deve­lo­pe­ra lub inte­gra­to­ra opro­gra­mo­wa­nia oraz treść moich spe­cy­fi­ka­cji jest dla Ciebie zro­zu­mia­ła i akcep­tu­jesz taką for­mę współ­pra­cy, zapra­szam do reje­stra­cji. Na tę listę wysy­łam cza­sa­mi tak­że pyta­nia o dostęp­ność ryn­ko­wą okre­ślo­nej tech­no­lo­gii. Moimi klien­ta­mi są i fir­my małe i bar­dzo duże, być może więć część tych zapy­tań nie będzie paso­wa­ła każdemu… 

„Jestem ​„C‑level” menedżerem”

Od wie­lu lat moi spon­so­rzy (zarzą­dy firm i dyrek­to­rzy zama­wia­ją­cy moje usłu­gi) mają moje peł­ne wspar­cie na eta­pie wybo­ru dostaw­cy i nego­cjo­wa­nia umów: po opra­co­wa­niu doku­men­ta­cji do pro­jek­tu wspie­ram moich klien­tów i pro­wa­dzę nad­zór autor­ski nad pra­ca­mi dostaw­ców. Zebrałem ogrom­ne doświad­cze­nie nie tyl­ko w ana­li­zie i pro­jek­to­wa­niu sys­te­mów, ale tak­że w obsza­rze pra­wa autor­skie­go w IT i ochro­ny know-how, któ­rym to doświad­cze­niem tak­że dzie­lę się na tym blo­gu. Jeżeli jesteś wła­ści­cie­lem fir­my two­rzą­cej opro­gra­mo­wa­nie lub mene­dże­rem w niej, to tak­że jest tema­ty­ka dla Ciebie.

Analiza, wymagania i usprawnianie organizacji: MBSE

?Cechy wyróż­nia­ją­ce nowo­cze­sną teo­rię orga­ni­za­cji to jej poję­cio­wo-ana­li­tycz­na pod­sta­wa, jej opar­cie się na danych uzy­ski­wa­nych z badań empi­rycz­nych, ale przede wszyst­kim jej syn­te­ty­zu­ją­cy, inte­gra­cyj­ny cha­rak­ter. Te cechy wyróż­nia­ją­ce są zawar­te w filo­zo­fii, któ­ra akcep­tu­je zało­że­nie, że jedy­nym spo­so­bem bada­nia orga­ni­za­cji jest trak­to­wa­nie ich jako sys­te­mów? (Kostrzewski et al., 1979).

Wprowadzenie

Wbrew ocze­ki­wa­niom, tak zwa­ne zwin­ne meto­dy (agi­le mani­fe­sto, 2001 r.) nie popra­wi­ły jako­ści pro­jek­tów infor­ma­tycz­nych, nie raz zaś spo­wo­do­wa­ły wzrost kosz­tów i wydłu­ża­nie ter­mi­nów, a z uwa­gi na sys­tem roz­li­czeń ​„czas i mate­riał”, nie pozwa­la­ją na pla­no­wa­nie budże­tu pro­jek­tu. Średnie i duże pro­jek­ty IT to nadal w ponad 80% poraż­ki .

Sprawdzają się jed­nak trud­niej­sze, ale znacz­nie sku­tecz­niej­sze, meto­dy zorien­to­wa­ne na mode­lo­wa­nie (ana­li­za sys­te­mo­wa i pro­jek­to­wa­nie) oraz rezy­gna­cja z mono­li­tycz­nej archi­tek­tu­ry sys­te­mów na rzecz archi­tek­tu­ry kom­po­nen­to­wej, wdra­ża­nej meto­da­mi ite­ra­cyj­no-przy­ro­sto­wy­mi . Metody te pozwo­li­ły na pro­jek­to­wa­nie roz­wią­zań infor­ma­tycz­nych i wdra­ża­nie ich w takt zmie­nia­ją­cych sie potrzeb. Pozwalają one tak­że na pla­no­wa­nie kosz­tów i ter­mi­nów już od począt­ku pro­jek­tu . Tak powsta­je tak zwa­na Specyfikacja SWS (Specyfikacja Wymagań Systemowych). 

Model Based Systems Engineering

Modelowanie pole­ga na abs­tra­ho­wa­niu od szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mecha­nizm .

MBSE to skrót od Model Based Systems Engineering (ang. inży­nie­ria sys­te­mów opar­ta na mode­lo­wa­niu) . System to nie tyl­ko ​„sys­tem infor­ma­tycz­ny”, to tak­że cała orga­ni­za­cja, a nawet Państwo. 

Celem tego krót­kie­go arty­ku­łu jest poka­za­nie stan­dar­do­wej ścież­ki ana­li­zy sys­te­mo­wej i popra­wy orga­ni­za­cji, czy­li meto­dy pro­wa­dze­nia ana­li­zy sta­nu obec­ne­go i pro­jek­to­wa­nia roz­wią­zań, opar­tej na ana­li­zie fak­tów i mode­lo­wa­niu , któ­rych celem jest opra­co­wa­nie reko­men­da­cji do ulep­sze­nia orga­ni­za­cji . W 2008 roku OMG opu­bli­ko­wa­ło spe­cy­fi­ka­cję Software & Systems Process Engineering Metamodel (SPEM?), opi­su­ją­cą pro­ces prac nad budo­wą sys­te­mów, jed­nak wyglą­da na to, że pra­ce nad tą spe­cy­fi­ka­cją nie są kon­ty­nu­owa­ne. MBSE jako meto­da, wyda­je się być następ­cą tego pomy­słu (patrz: Survey of Model-Based Systems Engineering (MBSE) Methodologies) .

.

Podstawą pra­cy z mode­la­mi w ana­li­zie sys­te­mo­wej orga­ni­za­cji jest ide­ali­za­cja . Polega ona tym by w toku ana­li­zy i poszu­ki­wa­nia roz­wią­za­nia zapro­jek­to­wać ide­ał (model orga­ni­za­cji w wer­sji ide­al­nej), następ­nie opra­co­wa­niu stu­dium jego wyko­nal­no­ści, uzu­peł­nie­niu ide­ału o pozna­ne ogra­ni­cze­nia i wdro­że­nia tak zapro­jek­to­wa­ne­go sys­te­mu . Studium wyko­nal­no­ści ide­ału to ofer­ty dostaw­ców roz­wią­zań, któ­rych rola jest nie ana­li­za a opra­co­wa­nie kon­cep­cji wdrożenia. . 

Trzy poziomy modelowanie organizacji

Organizacje moż­na opi­sać na trzech klu­czo­wych poziomach:

Enterprise Level – (poziom orga­ni­za­cji) jest to poziom, na któ­rym opi­su­je się i mode­lu­je, stra­te­gie orga­ni­za­cji i jej rolę w oto­cze­niu ryn­ko­wym (ryn­ko­wy łań­cuch war­to­ści). Dotyczy to tak­że insty­tu­cji publicz­nych. Taki opis jako krót­ki doku­ment, jest czę­sto dostęp­ny na stro­nach WWW orga­ni­za­cji w zakład­ce ​„O nas”, w pro­spek­tach emi­syj­nych, sta­tu­tach itp. Model powsta­je w toku for­ma­li­za­cji tego opisu. 

Business Process Level – to środ­ko­wy poziom, na któ­rym two­rzo­ny jest abs­trak­cyj­ny model orga­ni­za­cji w posta­ci tak zwa­ne­go wewnętrz­ne­go łań­cu­cha war­to­ści (pro­ces biz­ne­so­wy). Znakomita więk­szość orga­ni­za­cji nie ma takie­go doku­men­tu lub jest on nie­ak­tu­al­ny. Powodem tego sta­nu rze­czy jest to, że bie­żą­cej pra­cy ope­ra­cyj­nej jest on nie­po­trzeb­ny. Model taki przy­no­si jed­nak ogrom­ne korzy­ści w przy­pad­ku podej­mo­wa­niu decy­zji o zmia­nach. Jest to wte­dy pod­sta­wo­wy mate­riał obni­ża­ją­cy ryzy­ko wszel­kich decy­zji o jakich­kol­wiek zmia­nach orga­ni­za­cyj­nych lub pla­no­wa­nych wdrożeniach.

Implementation Level – to poziom opi­su­ją­cy szcze­gó­ły reali­zo­wa­nej pra­cy i wyko­rzy­sty­wa­nych narzę­dzi. To obszar tre­ści doku­men­tów takich jak: zakre­sy obo­wiąz­ków pra­cow­ni­ków i ich kom­pe­ten­cji, instruk­cje sta­no­wi­sko­we, pro­ce­du­ry, zarzą­dze­nia i regu­la­cje wewnętrz­ne, pod­ręcz­ni­ki uży­wa­nia sprzę­tu i opro­gra­mo­wa­nia oraz wie­le innych doku­men­tów o podob­nych cha­rak­te­rze. Dokumenty te są potrzeb­ne w bie­żą­cej pra­cy, jed­nak szyb­kie i sku­tecz­nie podej­mo­wa­nie decy­zji na ich pod­sta­wie ich tre­ści jest prak­tycz­nie nie­moż­li­we z uwa­gi na ich ilość i szczegółowość. 

Analiza biz­ne­so­wa pole­ga na audy­cie doku­men­tów ist­nie­ją­cych, czy­li tych z pozio­mu pierw­sze­go i trze­cie­go na powyż­szym dia­gra­mie, i opra­co­wa­niu na ich pod­sta­wie Modelu Procesów Biznesowych (środ­ko­wa war­stwa). Model ten to mecha­nizm funk­cjo­no­wa­nia orga­ni­za­cji, jej abs­trak­cyj­ny obraz, pozwa­la­ją­cy zapla­no­wać przy­szłe wdro­że­nie i prze­wi­dzieć jego efekty.

W toku ana­li­zy ma czę­sto miej­sce stan­da­ry­za­cja opi­su dzia­ła­nia i stra­te­gii. Jej celem jest for­ma­li­za­cja opi­su orga­ni­za­cji, bez cze­go nie jest moż­li­we doko­na­nie jakich­kol­wiek porów­nań np. z kon­ku­ren­cją, wyzna­cze­nie celów biz­ne­so­wych i wska­za­nie w orga­ni­za­cji miejsc mają­cych wpływ na te cele. 

Enterprise Level – Model biznesowy organizacji 

Strategia orga­ni­za­cji i jej rola w oto­cze­niu ryn­ko­wym są klu­czo­we dla zro­zu­mie­nia osią­ga­nych przez orga­ni­za­cję efek­tów. Mimo tego, że więk­szość orga­ni­za­cji dys­po­nu­je takim opi­sem, są one wyko­na­ne nie­for­mal­ny­mi meto­da­mi, tak róż­ny­mi, że jakie­kol­wiek porów­na­nie dwóch orga­ni­za­cji lub tej samej na prze­strze­ni lat jest prak­tycz­nie nie­moż­li­we. Dlatego opra­co­wa­no stan­dard zwa­ny Model Motywacji Biznesowej .

Standard ten sta­no­wi sobą pewien okre­ślo­ny sys­tem klu­czo­wych pojęć i związ­ków mię­dzy nimi. Jego celem jest stan­da­ry­za­cja pojęć takich jak: misja i wizja, stra­te­gia i tak­ty­ka, wewnętrz­ne i zewnętrz­ne czyn­ni­ki wpły­wu, cele i mier­ni­ki osią­ga­nia celu. 

Business Process Level – Model procesów biznesowych organizacji

Jest to model pozio­mu Business Process Level. To zna­czy, że nie ma tu miej­sca na szcze­gó­ły opi­sa­ne w doku­men­tach na pozio­mie Implementation Level. Model pro­ce­sów biz­ne­so­wych ma (powi­nien mieć) jedy­nie odno­śni­ki do szcze­gó­łów trze­ciej war­stwy, w szcze­gól­no­ści do pro­ce­dur, repre­zen­to­wa­nych na tym pozio­mie w posta­ci (abs­trak­cyj­nych) nazwa­nych aktywności.

Jednym z naj­bar­dziej zna­nych wzor­ców opi­su tego pozio­mu jest tak zwa­ny Wewnętrzny Łańcuch Wartości M. Portera, jest on nadal pod­sta­wo­wą wie­dzą każ­de­go absol­wen­ta stu­diów MBA. Model ten zakła­da podział pro­ce­sów na wspie­ra­ją­ce (admi­ni­stra­cja) i ope­ra­cyj­ne. Konkurencyjność i spraw­ność ope­ra­cyj­na ma dwa obsza­ry: w obsza­rze admi­ni­stra­cji, ści­śle regu­lo­wa­nym pra­wem, w zasa­dzie kon­ku­ru­je­my kosz­ta­mi, ale w obsza­rze ope­ra­cyj­nym, dają­cym znacz­nie więk­szą swo­bo­dę jego kształ­to­wa­nia, kon­ku­ren­cyj­ność to efekt spraw­no­ści orga­ni­za­cji, archi­tek­tu­ry pro­ce­sów biz­ne­so­wych i informacji. 

Łańcuch wartości M.E.Porter
Wewnętrzny łań­cuch wartości 

Z ww. powo­du w toku ana­li­zy i mode­lo­wa­nia sku­pia­my sie na obsza­rze ope­ra­cyj­nym, gdyż obszar wspar­cia admi­ni­stra­cyj­ne­go, z powo­du ści­słej zależ­no­ści od pra­wa, moż­na wes­przeć stan­dar­do­wym opro­gra­mo­wa­niem, łatwo dostęp­nym na ryn­ku. Ewentualne dedy­ko­wa­ne modu­ły są pro­jek­to­wa­ne wła­śnie dla obsza­ru ope­ra­cyj­ne­go, bo to tu wystę­pu­ją róż­ni­ce mię­dzy orga­ni­za­cja­mi i tu powsta­je prze­wa­ga kon­ku­ren­cyj­na (jeże­li doty­czy to orga­ni­za­cji kon­ku­ru­ją­cej na ryn­ku). Kluczem na tym eta­pie jest wska­za­nie miejsc do uspraw­nie­nia i opra­co­wa­nie roz­wią­za­nia. Próby kom­plek­so­we­go wdra­ża­na ​„jed­ne­go sys­te­mu do wszyst­kie­go” naj­czę­ściej koń­czą się nie­ste­ty źle (kom­plek­so­we wdro­że­nia mono­li­tów ERPII mają bar­dzo złą reno­mę). Model Portera odno­si sie jed­na­ko­wym stop­niu do firm ryn­ko­wych jak i do insty­tu­cji publicznych. 

Więcej w arty­ku­le Analiza orga­ni­za­cji i opra­co­wa­nie Mapy Procesów.

Implementation Level – wdrożenie

Ten poziom i jego doku­men­ta­cja, to tak na praw­dę efekt pra­cy ope­ra­cyj­nej i pro­dukt wdro­że­nia norm jako­ści i pro­ce­dur, stra­te­gii zatrud­nie­nia, sys­te­mu infor­ma­tycz­ne­go itp. (patrz Operational Resources w poprzed­nim pod­roz­dzia­le). Tę doku­men­ta­cję two­rzą dostaw­cy roz­wią­zań oraz wewnętrz­ne służ­by admi­ni­stra­cji. Jako, że ona w róż­nych for­mach ist­nie­je w każ­dej fir­mie, sta­no­wi bazo­wy mate­riał źró­dło­wy w ana­li­zach sta­nu obec­ne­go. To dla­te­go ana­li­zę orga­ni­za­cji moż­na prze­pro­wa­dzić prak­tycz­nie w 100% bez kło­po­tli­wych i kosz­tow­nych spo­tkań warsz­ta­to­wych z pra­cow­ni­ka­mi ana­li­zo­wa­ne­go podmiotu. 

Rozwiązania informatyczne i wymagania

Niestety same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych to wyłącz­nie idea jego powsta­nia (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su, dają­cą ochro­nę w posta­ci peł­ne­go pra­wa do powsta­łe­go pro­duk­tu, uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt jego kon­struk­cji, struk­tur danych i mecha­ni­zmu dzia­ła­nia, sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we.

Obecne cza­sy to wszech­obec­na cyfry­za­cja. Dlatego zna­ko­mi­ta więk­szość roz­wią­zań wspie­ra­ją­cych dzia­ła­nia orga­ni­za­cji to sys­te­my infor­ma­cyj­ne wspie­ra­ją­ce pro­ce­sy biznesowe. 

Powyżej poka­za­no (zna­ny od lat 90-tych ubie­głe­go wie­ku) model archi­tek­tu­ry sys­te­mów infor­ma­cyj­nych zorien­to­wa­nej na usłu­gi apli­ka­cyj­ne. Pokazuje on związ­ki pomię­dzy pro­ce­sa­mi biz­ne­so­wy­mi a sys­te­ma­mi infor­ma­cyj­ny­mi, któ­rych doce­lo­wo w każ­dej orga­ni­za­cji jest wię­cej niż jeden. 

Systemy infor­ma­cyj­ne tak­że mode­lu­je­my na kil­ku poziomach: 

  1. Business Services – jako nazwa­ne usłu­gi biz­ne­so­we wyma­ga­ją­ce okre­ślo­nych usług apli­ka­cyj­nych, wspie­ra­ją­cych okre­ślo­ne aktyw­no­ści w pro­ce­sach, usłu­gi apli­ka­cyj­ne mode­lu­je­my jako przy­pad­ki uży­cia apli­ka­cji (są to wyma­ga­nia na rozwiązanie),
  2. Components – jako nazwa­ne i wyspe­cy­fi­ko­wa­ne kom­po­nen­ty apli­ka­cyj­ne wraz z ich inte­gra­cją (jest to opis rozwiązania),
  3. Operational Resources – jako model opi­su­ją­cy fak­tycz­ne ich wdro­że­nie i roz­lo­ko­wa­nie (jest to doku­men­ta­cja wdro­żo­ne­go systemu). 

Kluczowymi sto­so­wa­ny­mi stan­dar­da­mi nota­cyj­ny­mi są tu BPMN, UML, SBVR . Więcej w arty­ku­le Analiza i opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie.

Opracowanie spe­cy­fi­ka­cji wyma­gań (mode­li) nie powin­no nigdy w obec­nych cza­sach trwać dłu­żej niż kwar­tał, co ozna­cza, że im więk­szy pro­jekt tym bar­dziej spe­cy­fi­ka­cja wyma­gań jest poli­ty­ką (archi­tek­tu­rą) niż deta­licz­nym opi­sem. Detale są spe­cy­fi­ko­wa­ne już w toku wdro­że­nia w toku nad­zo­ru autor­skie­go, zgo­dzie z poli­ty­ką budo­wy i wdra­ża­nia sys­te­mu (archi­tek­tu­rą). Wycena reali­za­cji nie powin­na spra­wić kło­po­tu, żad­nej doświad­czo­nej, zna­ją­cej wzor­ce archi­tek­to­nicz­ne, fir­mie ofru­ją­cej oprogramowanie. 

Praca z dostawcami rozwiązań

Praktycznie zawsze pada pyta­nie: a co jeże­li dostaw­ca też robi ana­li­zę przed­wdro­że­nio­wą? Otóż tu już jej nie robi bo ją dosta­je. Z uwa­gi na ryzy­ko pro­jek­tu i poten­cjal­ny kon­flikt inte­re­su, Dostawca z zasa­dy nie powi­nien być auto­rem wyma­gań (pro­jek­tu rozwiązania). 

Dostawca musi opra­co­wać pro­po­no­wa­ną przez sie­bie Koncepcję Wdrożenia ofe­ro­wa­ne­go pro­duk­tu, w odpo­wie­dzi na wyma­ga­nia wyra­żo­ne w posta­ci mode­li pro­ce­sów biz­ne­so­wych, struk­tur doku­men­tów i reguł biz­ne­so­wych (Model Biznesowy Organizacji). Z uwa­gi na to, że pro­jek­ty takie zawsze reali­zo­wa­ne są meto­dą ite­ra­cy­no-przy­ro­sto­wą, w toku pro­jek­tu ma miej­sce sta­ła współ­pra­ca: Dostawca roz­wią­za­nia żąda kolej­nych deta­licz­nych infor­ma­cji o tym jak dzia­ła fir­ma Zamawiającego, Zamawiający, z moją pomo­cą (nad­zór autor­ski), odpo­wia­da odsy­ła­jąc sta­le uzu­peł­nia­ny Model Biznesowy. Dostawca doku­men­tu­je kolej­ne eta­py pro­wa­dzo­ne­go wdro­że­nia (aktu­ali­zu­je Koncepcję Wdrożenia, któ­ra sta­je się doku­men­ta­cją tego wdro­że­nia) a ja je (te doku­men­ty) wery­fi­ku­ję, i tak aż do zakoń­cze­nia wdrożenia. 

Na koniec wdro­że­nia Zamawiający dys­po­nu­je dwo­ma aktu­al­ny­mi doku­men­ta­mi: Model Biznesowy (środ­ko­wa war­stwa opi­su orga­ni­za­cji) i Dokumentacja Wdrożenia (opi­sa­ny wyżej Poziom Implementacji).

Podsumowanie

Każdy pro­jekt zwią­za­ny z reor­ga­ni­za­cją i/lub wdra­ża­niem nowe­go opro­gra­mo­wa­nia (zmian, roz­bu­do­wy) moż­na więc prze­pro­wa­dzić meto­dą ana­li­zy orga­ni­za­cji i jej mode­lo­wa­nia na z góry usta­lo­nym pozio­mie szcze­gó­ło­wo­ści. Modele te są ści­śle zin­te­gro­wa­ne z sobą, a całość ma cha­rak­ter opi­su ​„od ogó­łu do szczegółu”. 

Podejście to gwa­ran­tu­je spój­ność, kom­plet­no­ści i nie­sprzecz­ność opi­su na każ­dym eta­pie pro­jek­tu. Dzięki temu mini­ma­li­zu­je­my ryzy­ko nie­uda­ne­go wdro­że­nia a całość trwa krót­ko (żaden etap ana­li­zy nie powi­nien trwać dłu­żej niż kwar­tał!). Prosty ale obra­zo­wy przy­kład opi­sa­łem TUTAJ.

Całość lite­ra­tu­ra przed­mio­tu opi­su­je od wie­lu lat, meto­dy te są sta­le dosko­na­lo­ne. Poniżej pro­ces two­rze­nia opro­gra­mo­wa­nia jako pro­jek­to­wa­nie systemu: 

Model sys­te­mu jest celem ana­li­zy opar­tej o przy­pad­ki uży­cia (wywo­dzo­ne z pro­ce­sów biz­ne­so­wych) i ich sce­na­riu­sze, na ich pod­sta­wie powsta­je model sys­te­mu, kolej­ny krok to imple­men­ta­cja (code) jed­nak nadal dłu­go jesz­cze będzie to pra­ca dla deve­lo­pe­rów .

Przypadki uży­cia (use case) to wynik opi­sa­nej na począt­ku ana­li­zy biz­ne­so­wej (orga­ni­za­cja to tak­że sys­tem) i wyod­ręb­nie­nia celów biz­ne­so­wych. Mamy rok 2021 i ogrom­ny wybór dostęp­ne­go, goto­we­go opro­gra­mo­wa­nia wyma­ga­ją­ce­go jedy­nie wła­ści­we­go dobo­ru i inte­gra­cji. Tak opi­sa­ny wyżej sys­tem to struk­tu­ra i zacho­wa­nie się dobra­nych kom­po­nen­tów, nie koniecz­nie jest to ​„pisa­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia od zera”, bo to ma miej­sce coraz rza­dziej i doty­czy ewen­tu­al­nie 10 – 15% dedy­ko­wa­nych potrzeb nie­któ­rych firm. 

Obecne na ryn­ku sys­te­my wspie­ra­ją­ce ana­li­zy i pro­jek­to­wa­nie (CASE: Computer Aided System Engineering) oraz wzor­ce archi­tek­to­nicz­ne i narzę­dzia infor­ma­tycz­ne, pozwa­la­ją pro­wa­dzić ana­li­zy i mode­lo­wa­nie eta­pa­mi trwa­ją­cy­mi poje­dyn­cze tygo­dnie a nie lata. Iteracyjno-przy­ro­stwe meto­dy dostar­cza­nia opro­gra­mo­wa­nia pozwa­la­ją wdra­żać nowo­cze­sne roz­wią­za­nia w okre­sach kwar­tal­nych a nie lat. 

Poniżej pro­sty przy­kład pro­duk­tu takiej pracy:

[down­lo­ad id=„28199”]

Sprawdź aktu­al­ne kosz­ty takie­go pro­jek­tu: KOSZT.

Źródła

Sienkiewicz, P. (1994). Analiza sys­te­mo­wa: pod­sta­wy i zasto­so­wa­nia. Wydaw. Bellona.
Hart, L. E. (2015). Introduction To Model-Based System Engineering (MBSE) and SysML. Delaware Valley INCOSE Chapter Meeting, 43. https://​www​.inco​se​.org/​d​o​c​s​/​d​e​f​a​u​l​t​-​s​o​u​r​c​e​/​d​e​l​a​w​a​r​e​-​v​a​l​l​e​y​/​m​b​s​e​-​o​v​e​r​v​i​e​w​-​i​n​c​o​s​e​-​3​0​-​j​u​l​y​-​2​0​1​5​.​pdf
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2015, April). Business Motivation Model (BMM). https://​www​.omg​.org/​s​p​e​c​/​B​MM/
Estefan, J. A. (2007). Survey of Model-Based Systems Engineering (MBSE) Methodologies. 47.
Harel, D. (2000). From play-in sce­na­rios to code: An achie­va­ble dre­am. International Conference on Fundamental Approaches to Software Engineering, 22 – 34.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
BPTrends Associates. (2020). BPTrends Associates | BPM ana­ly­sis, opi­nion and insi­ght. http://​www​.bptrend​sas​so​cia​tes​.com/
Suri, K., Cuccuru, A., Cadavid, J., Gerard, S., Gaaloul, W., & Tata, S. (2017). Model-based Development of Modular Complex Systems for Accomplishing System Integration for Industry 4.0: Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development, 487 – 495. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​6​2​1​0​5​0​4​8​7​0​495
The Standish Group International, Inc. (2015). Chaos Report 2015 (No. 2015; p. 13). https://​www​.stan​di​sh​gro​up​.com/​s​a​m​p​l​e​_​r​e​s​e​a​r​c​h​_​f​i​l​e​s​/​C​H​A​O​S​R​e​p​o​r​t​2​0​1​5​-​F​i​n​a​l​.​pdf
Jones, S. (2006). Enterprise SOA adop­tion stra­te­gies: using SOA to deli­ver IT to the busi­ness. C4Media.
Koźmiński, A. K. (1979). Decyzje: ana­ly­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Jenney, J., Gangl, M., Kwolek, R., Melton, D., Ridenour, N., & Coe, M. (2010). Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Joe Jenney.
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.
http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Zwinna analiza biznesowa to mit czy fakt?

4 komentarze

Agile busi­ness ana­lyst has the capa­bi­li­ty to keep the whe­el rol­ling. They?re a trans­for­ma­ti­ve fun­nel thro­ugh which a requ­ire­ment pas­ses down to the deli­ve­ry path towards an expec­ted out­co­me. This SDLC machi­ne needs con­ti­nu­ous fuel in the form of well-defi­ned and infor­med infor­ma­tion which is pro­vi­ded by an agi­le busi­ness ana­lyst. As long as an agi­le busi­ness ana­lyst does the job, this machi­ne will rema­in on its cour­se to deli­ver gre­ater solutions.Coming to our ori­gi­nal question, is an agi­le busi­ness ana­lyst a myth or a reali­ty? There is a cle­ar answer. It is a reali­ty if an orga­ni­za­tion reali­zes the value, but it is a myth for imma­tu­re orga­ni­za­tions who­se pro­ces­ses are ill-defi­ned and are nowhe­re on a path towards best prac­ti­ces. (Is Agile Business Analyst a Myth or a Reality? )

Tak więc (zwin­ny) ana­li­tyk biz­ne­so­wy to model pra­cy pole­ga­ją­cy na sta­łym dostar­cza­niu (na eta­pie imple­men­ta­cji) kolej­nych infor­ma­cji. Projekt two­rze­nia apli­ka­cji zawsze trwa w cza­sie, więc w toku two­rze­nia opro­gra­mo­wa­nia zmie­nia się biznes. 

Developerzy czę­sto mówią, że klient zmie­nia im wyma­ga­nia, a tak na praw­dę ktoś zbyt wcze­śnie zapi­sał zbyt wie­le szcze­gó­łów. Implementacja dedy­ko­wa­ne­go opro­gra­mo­wa­nia to tak na praw­de pętla ite­ra­cyj­no-przy­ro­sto­wa: zbie­ra­my infor­ma­cje potrzeb­ne do wytwo­rze­nia jed­nej usłu­gi apli­ka­cyj­nej i imple­men­tu­je­my ją, wszel­kie szcze­gó­ły odkła­da­my na ostat­ni moment. Wymaga to jed­nak zmia­ny podej­ścia. Trzy lata temu pisa­łem na tym blogu:

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie ??water­fall?. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­­ra­­cy­j­no-przy­­ro­­sto­­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na ryn­ku.Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak ??inży­nie­ria wyma­gań? bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no ??inży­nie­rię sys­te­mów?.? sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. opro­gra­mo­wa­nie? (Wymagania umar­ły. Rozwiązaniem jest cykl życia pro­duk­tu | | Jarosław Żeliński IT-Consulting)

Z cze­go nale­ży więc od razu zre­zy­gno­wać? Z opra­co­wa­nia rela­cyj­ne­go mode­lu (bazy) danych dla całej apli­ka­cji, i prze­sta­wić sie na idee mikro-ser­wi­sów, czy­li uzna­nia, że apli­ka­cja nie jest mono­li­tem a zesta­wem kom­po­nen­tów reali­zu­ją­cych usłu­gi apli­ka­cyj­ne. Usługi apli­ka­cyj­ne mode­lu­je­my jako Przypadki Użycia (nota­cja UML) i to sta­no­wi kon­takt z dostaw­cą. Jednak ​„czar­na skrzyn­ka” (opis nie zawie­ra­ją­cy mecha­ni­zmu dzia­ła­nia) jest bar­dzo ryzy­kow­ny, dla­te­go sku­tecz­ne meto­dy doku­men­to­wa­nia wyma­gań, to meto­dy zorien­to­wa­nie na mode­le (MDA) opi­su­ją­ce logi­kę dzia­ła­nia sys­te­mu (model jako wyma­ga­nie), a zamiast two­rze­nia kor­po­ra­cyj­ne­go rela­cyj­ne­go mode­lu danych, zamy­ka­my się w doku­men­tach jako ele­men­tar­nych nośni­kach danych (i nie boimy sie redun­dan­cji danych w całym sys­te­mie). Ogromne i szcze­gó­ło­we doku­men­ty i mode­le są wyłącz­nie stra­tą cza­su i pieniędzy:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Dlatego od lat fascy­nu­je mnie nie­kon­se­kwen­cja wie­lu deve­lo­pe­rów: naj­pierw wie­sza­ją psy na meto­dach nazy­wa­nych ​„water­fall”, a już chwi­lę potem zaczy­na­ją pro­jek­to­wa­nie jed­ne­go rela­cyj­ne­go mode­lu danych dla całe­go projektu! 

Zwinny Analityk Biznesowy utrzy­mu­je pętlę ite­ra­cji przy­ro­stu zakre­su pro­jek­tu: mając opra­co­wa­ną archi­tek­tu­rę cało­ści i para­dyg­mat (poli­ty­kę) pro­jek­to­wa­nia (np. obiek­to­wy), dostar­cza cyklicz­nie i zawsze na ostat­ni moment, kolej­ne szcze­gó­ły, bo wte­dy ma naj­więk­szą wie­dzę, i ryzy­ko zmia­ny zakre­su jest naj­mniej­sze. To się nazy­wa «nad­zór autorski».

Tak więc klu­czem do suk­ce­su, w dzi­siej­szych warun­kach, jest model opar­ty na kom­po­nen­to­wej archi­tek­tu­rze i ite­ra­cyj­nym dostar­cza­niu kolej­nych usług apli­ka­cyj­nych . Jak? Analiza, pro­jek­to­wa­nie i implementacja:

  • Analiza biz­ne­so­wa (pro­ce­sy biz­ne­so­we) i sys­te­mu infor­ma­cji w orga­ni­za­cji, i decy­zja o ewen­tu­al­nej stan­da­ry­za­cji doku­men­tów i pro­ce­sów. (nota­cje BMM, SBVR, BPMN, UML)
  • Opracowanie mode­lu infor­ma­cyj­ne­go czy­li sza­blo­nów doku­men­tów, ich wza­jem­nych powią­zań i słow­ni­ka pojęć. (nota­cja UML, SBVR)
  • Opracowaniu archi­tek­tu­ry cało­ści i opi­sa­nie cyklu życia pro­jek­tu (nota­cja UML).
  • Przejścia do fazy imple­men­ta­cji z nad­zo­rem autor­skim auto­ra pro­jek­tu (zarzą­dza­nie zmia­ną, sta­ła aktu­ali­za­cja doku­men­ta­cji systemu).

Pierwsze przy punk­ty, ich reali­za­cja, nie powin­ny nigdy trwać dużej niż kwar­tał, a doku­men­ta­cja pier­wot­na raczej nie powin­na prze­kro­czyć nigdy 100 stron, bez wzglę­dy na wiel­kość pro­jek­tu! Im więk­szy pro­jekt tym bar­dziej doku­men­ta­cja począt­ko­wa powin­na być abs­trak­cyj­nym mode­lem. Innymi sło­wy: im więk­szy i dłu­żej trwa­ją­cy pro­jekt, tym bar­dziej jego opis powi­nien być stra­te­gią jego reali­za­cji, a nie taktyką. 

Czy zwin­ny ana­li­tyk biz­ne­so­wy jest mitem czy rze­czy­wi­sto­ścią? Istnieje jasna odpo­wiedź: to rze­czy­wi­stość, jeśli orga­ni­za­cja zda­je sobie spra­wę z war­to­ści takiej pra­cy, ale jest mitem dla nie­doj­rza­łych orga­ni­za­cji, któ­rych pro­ce­sy są źle zdefiniowane.

Źródła

Steve Burbeck (2012) How to use Model-View-Controller (MVC). Available at: https://web.archive.org/web/20120729161926/http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html (Accessed: 5 January 2020).
Jenney, J. et al. (2010) Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Erscheinungsort nicht ermit­tel­bar: Joe Jenney.
Awaysheh, F.M. et al. (2019) ​‘Next-Generation Big Data Federation Access Control: A Reference Model’, arXiv:1912.11588 [cs] [Preprint]. Available at: http://​arxiv​.org/​a​b​s​/​1​9​1​2​.​1​1​588 (Accessed: 4 January 2020).
Garland, J. and Anthony, R. (2003) Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. Chichester ; New York: J. Wiley.
Kumar, R.N.P. and Patil, S. (2019) ​‘A System and Method for impro­ving the Model Based Systems Engineering Environment capa­bi­li­ty’, INCOSE International Symposium, 29(S1), pp. 277 – 290. http://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2019.00685.x.

Generator Ofert – Komentarze

2 komentarze

Wprowadzenie

Oprogramowanie Generator Ofert zosta­ło zapro­jek­to­wa­ne prze­ze mnie dla Biura Polonijnego Kancelarii Senatu. Zadanie jakie dosta­łem to opra­co­wa­nie wyma­gań (Opis Przedmiotu Zamówienia) na apli­ka­cję, która:

  • pozwa­la skła­dać wnio­ski na dofi­nan­so­wa­nie pro­jek­tów Polonii z całe­go świata,
  • skła­dać wnio­ski sta­no­wią­ce for­mu­la­rze o bar­dzo roz­bu­do­wa­nej i zmien­nej w cza­sie struk­tu­rze, prze­cho­wy­wać ich kolej­ne wersje,
  • pro­wa­dzić pro­ces oce­ny wnio­sków przez eks­per­tów Bura Polonii Kancelarii Senatu,
  • two­rzyć i zawie­rać umo­wy, w któ­rych te wnio­ski są załącznikiem, 
  • śle­dzić roz­li­cza­nie tych umów.
  • pro­wa­dzi archi­wum tych dokumentów,

Analizę i pro­jekt zre­ali­zo­wa­łem zdal­nie sam, w cią­gu mie­sią­ca (komu­ni­ka­cja). W toku prze­tar­gu nie było żad­nych skarg na treść OPZ do KIO. Implementacja wyko­na­na w cią­gu pię­ciu mie­się­cy w budzę­cie i ter­mi­nie, pod moim nad­zo­rem (nad­zór autorski). 

Łączny koszt (ana­li­za plus pra­ce deve­lo­pe­ra) zaję­ły mniej niż 6 mie­się­cy kosz­tem ok. 500tys. Aplikacja nadal dzia­ła i jest rozwijana. 

(w 2019 roku kolej­ny prze­targ na roz­wój, OPZ nadal wyko­rzy­stu­je pod­sta­wy moje­go pro­jek­tu: https://​www​.senat​.gov​.pl/​g​f​x​/​s​e​n​a​t​/​u​s​e​r​f​i​l​e​s​/​_​p​u​b​l​i​c​/​k​8​/​k​a​n​c​e​l​a​r​i​a​/​z​a​m​/​2​0​1​9​/​1​5​/​c​a​l​o​s​c​.​pdf)

Całość jest na AZURE. Aplikacja dzia­ła do dziś w dobrej kon­dy­cji, jest rela­tyw­nie tania w utrzy­ma­niu mimo corocz­nych zmian prze­pi­sów (w tym for­mu­la­rzy). Poprzednie wyce­ny (nie­któ­re na bazie metod opar­tych o punk­ty funk­cyj­ne, inne na bazie wie­lo­dnio­wych warsz­ta­tów z pra­cow­ni­ka­mi Kancelarii Senatu czy te na bazie setek stron mode­li UML baz danych i nie­zro­zu­mia­łych dia­gra­mów UC), dawa­ły wie­lo­krot­nie (bywa­ły ponad 10 krot­nie) wyż­sze pro­gno­zy kosztów. 

Dokument sta­no­wią­cy Opis Przedmiotu Zamówienia (pro­jekt tech­nicz­ny) jest dostęp­ny na stro­nie BIP Kancelarii pod adre­sem: https://​www​.senat​.gov​.pl/​g​f​x​/​s​e​n​a​t​/​u​s​e​r​f​i​l​e​s​/​_​p​u​b​l​i​c​/​k​8​/​k​a​n​c​e​l​a​r​i​a​/​z​a​m​/​2​0​1​7​/​1​5​/​z​a​l​a​c​z​n​i​k​_​n​r​_​1​_​d​o​_​s​i​w​z​.​pdf dla­te­go czę­sto słu­ży mi za przy­kła­do­wą refe­ren­cję. Z uwa­gi na to, że mie­wam pyta­nia o kon­struk­cję sche­ma­tów blo­ko­wych uży­te w tym doku­men­cie, omó­wię je tu pokrót­ce. Między inny­mi cał­ko­wi­cie zre­zy­gno­wa­łem z SQL i rela­cyj­ne­go mode­lu danych dla for­mu­la­rzy, dzię­ki cze­mu wie­lo­krot­nie spa­dła pra­co­chłon­ność wytwo­rze­nia oraz póź­niej­sze kosz­ty utrzy­ma­nia i roz­wo­ju (mię­dzy inny­mi co roku nie­co zmie­nio­ne formularze). 

W takich pro­jek­tach bar­dzo waż­ny jest nad­zór autor­ski, czy­li tu mój udział w pro­jek­cie w toku implementacji: 

  1. nad­zo­ru­ję pra­cę dewelopera,
  2. na bie­żą­co wyja­śniam wąt­pli­wo­ści deve­lo­pe­ra co do dokumentacji,
  3. na bie­żą­co uzu­peł­niam doku­ment o nowe ele­men­ty (czas się nie zatrzy­mu­je w dniu ogło­sze­nia prze­tar­gu i pod­pi­sa­niu umo­wy z wykonawcą),
  4. na bie­żą­co aktu­ali­zu­ję doku­men­ta­cję o wszel­kie pod­ję­te decy­zje architektoniczne,
  5. w dniu odda­nia apli­ka­cji do użyt­ku, sta­le aktu­ali­zo­wa­ny OPZ, sta­no­wi aktu­al­ną doku­men­ta­cję powsta­łe­go sys­te­mu, tu na koniec nad­zo­ru, miał nie­co ponad 80 stron. 

(Dokument OPZ został w cało­ści wyko­na­ny z uży­ciem opro­gra­mo­wa­nia Visual-Paradigm: wbu­do­wa­ne­go edy­to­ra DocComposer pakie­tu Visual-Paradigm. Cały cykl pra­cy nad wyma­ga­nia­mi i ich doku­men­to­wa­niem nie wyma­ga uży­cia żad­nych narzę­dzi biu­ro­wych typu Office.)

Zakres

Na tym dia­gra­mie kolo­ra­mi poka­za­no zakres odpo­wie­dzial­no­ści Zamawiającego i Wykonawcy. Kolor nie­bie­ski ozna­cza pro­duk­ty, któ­re ma dostar­czyć Wykonawca. Jest to dia­gram przy­pad­ków uży­cia nota­cji UML. Zależności (uza­leż­nie­nia) zosta­ły zamo­de­lo­wa­ne stan­dar­do­wym związ­kiem zależ­no­ści w UML. W tej posta­ci dia­gram ten czę­sto nazy­wa­ny jest Modelem Kontekstowym.

Cele biznesowe

Powyższy dia­gram to model moty­wa­cji biz­ne­so­wej (BMM). Jest to bar­dzo waż­ny dia­gram w pro­jek­cie: słu­ży do okre­śle­nia celu biz­ne­so­we­go. Jest uży­wa­ny do selek­cji zgła­sza­nych wyma­gań biz­ne­so­wych. Do zakre­su pro­jek­tu powin­ny być kwa­li­fi­ko­wa­ne wyłącz­nie wyma­ga­nia wspie­ra­ją­ce cele biz­ne­so­we pro­jek­tu. Pozwala to sku­tecz­nie zarzą­dzać zakre­sem projektu.

Słownik i model pojęciowy

Co do zasa­dy pro­jekt powi­nien mieć Biznesowy słow­nik pojęć. Jest to lista pojęć wraz z ich defi­ni­cja­mi, któ­rej celem jest zagwa­ran­to­wa­nie jed­no­znacz­no­ści tre­ści całej doku­men­ta­cji. Są to poję­cia dzie­dzi­no­we a słow­nik ten sta­no­wi prze­strzeń poję­cio­wą dla innych dia­gra­mów. Diagram ten stan­dar­do­wo wyko­nu­ję jako Model Faktów nota­cji SBVR, ale jest to tak napraw­dę dia­gram klas skła­da­ją­cy się wyłącz­nie z klas, związ­ków gene­ra­li­za­cji i skie­ro­wa­nych aso­cja­cji. Celem jego budo­wy jest zagwa­ran­to­wa­nie spój­no­ści i nie­sprzecz­no­ści pojęć w słow­ni­ku. Cechą tego dia­gra­mu (meto­dą kon­tro­li jego popraw­no­ści) jest to, że każ­de dwa połą­czo­ne skie­ro­wa­ną aso­cja­cją poję­cia, two­rzą (powin­ny) popraw­ne zda­nie w języ­ku natu­ral­nym np. ?metry­ka zawie­ra fak­ty z histo­rii spra­wy? czy ?umo­wa jest typem pisma?. Nazwy klas, atry­bu­tów, ope­ra­cji, akto­rów itp. na pozo­sta­łych dia­gra­mach muszą pocho­dzić z tej prze­strze­ni pojęciowej!

Poglądowa mapa procesów biznesowych

Bardzo przy­dat­nym dia­gra­mem jest nie­for­mal­ny sche­mat blo­ko­wy obra­zu­ją­cy pro­ce­sy biz­ne­so­we ope­ra­cyj­ne. Każdy ?pago­nik? to abs­trak­cja pro­ce­su, któ­re­go deta­le poka­za­ne zosta­ną na dedy­ko­wa­nych dia­gra­mach w nota­cji BPMN. Można taki dia­gram tak­że wyko­nać w nota­cji BPMN, jed­nak jego adre­sa­tem są spon­so­rzy pro­jek­tu, któ­rzy rzad­ko mają łatwość posłu­gi­wa­nia sie nota­cją BPMN. 

Podmioty w otoczeniu Kancelarii

Diagram współ­pra­cy nota­cji BPMN jest two­rzo­ny w celu inwen­ta­ry­za­cji pod­mio­tów zaan­ga­żo­wa­nych w pro­ce­sach obsłu­gi wnio­sków. Nazwy tych pod­mio­tów sta­no­wią poten­cjal­ne war­to­ści atry­bu­tów meta­da­nych doku­men­tów, będą tak­że uży­te jako pule na dia­gra­mach BPMN.

Zarządzanie przepływem dokumentów

Diagram BPMN, na któ­rym poka­za­no czyn­no­ści zwią­za­ne z pra­cą z doku­men­ta­mi. W takich przy­pad­kach, gdzie ludzie wyko­nu­ją czyn­no­ści sami dobie­ra­jąc ich kolej­ność wg. usta­lo­nych reguł (np. w instruk­cjach) nie ma sen­su mode­lo­wa­nie wszel­kich warian­tów z uży­ciem wiel­kiej ilo­ści bra­mek i moż­li­wych prze­pły­wów (spe­cy­fi­ka­cja BPMN 2.0.2, Figury 10.35, 10.36, 10.37).

Jeżeli prze­pływ pra­cy jest bar­dziej deter­mi­ni­stycz­ny powsta­ją dia­gra­my jak poniżej.

Przypadki użycia ? usługi aplikacyjne

Diagram przy­pad­ków uży­cia ma poka­zać usłu­gi apli­ka­cyj­ne i inte­re­sa­riu­szy sys­te­mu (ludzi) oraz ewen­tu­al­nych akto­rów będą­cych inny­mi apli­ka­cja­mi (inte­gra­cje). Tu wyjąt­ko­wo uży­łem dość rzad­kiej kon­struk­cji jaką jest gene­ra­li­za­cja (a nie dzie­dzi­cze­nie! któ­re­go nie ma w UML od 2015 roku, od wer­sji 2.5), poka­zu­ją­ca że zarów­no recen­zen­ci jaki refe­ren­ci to pra­cow­ni­cy Kancelarii. To uogól­nie­nie to słow­ni­ko­wy zabieg mają­cy na celu uprosz­cze­nie dia­gra­mu (jeden zwią­zek zależ­no­ści do gene­ra­li­za­cji zamiast dwóch do jej instan­cji). Jest to zabieg słow­ni­ko­wy, ana­lo­gicz­ny to tego, w któ­rym mówi­my ?wete­ry­narz leczy zwie­rzę­ta? zamiast mówić ?wete­ry­narz leczy, psy, koty, świn­ki mor­skie? (sło­wo zwie­rzę­ta jest słow­ni­ko­wą gene­ra­li­za­cją kon­kret­nych zwie­rząt). Tej rzad­ko uży­wa­nej kon­struk­cji uży­łem tyl­ko z powo­du pre­sji czas i odra­dzam ją. Lepszą kon­struk­cją była by tu struk­tu­ral­na meta­kla­sa zamiast uogól­nie­nia i związ­ki «instanceOf» zamiast poję­cio­wej gene­ra­li­za­cji, a jesz­cze pro­ściej poka­zać te zależ­no­ści wyłącz­nie na mode­lu pojęciowym. 

Model dziedziny

Został wyko­na­ny z uży­ciem stan­dar­do­we wzor­ca BCE, nie raz już opi­sy­wa­ne­go na tym blo­gu, po pra­wej stro­ny, poka­za­no wybra­ne deta­le struk­tu­ry repo­zy­to­riów jako realizacje.

Powyższe to wybra­ne klu­czo­we ele­men­ty projektu.

Podsumowanie

Pozostałe ele­men­ty OPZ dla Kancelarii Senatu wyda­ją mi się dość oczy­wi­ste, tu sta­ra­łem się sko­men­to­wać te ele­men­ty tego doku­men­tu, któ­re budzą naj­wię­cej pytań i emo­cji. Są to bar­dzo przy­dat­ne i nie­do­ce­nia­ne kon­struk­cje zarów­no w nota­cji UML jak i BPMN.

Zainteresowanych podob­nym i upu­blicz­nio­nym pro­jek­tem zapra­szam tu: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? pro­jekt badawczy.