Diagram Przypadków Użycia UML

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

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

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.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/

Odpowiedzialność administratora systemu

Wstęp

pra­wie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w ??doku­men­ta­cji wyma­gań?. Jakim wyma­ga­niem jest ??zgod­ność z obo­wią­zu­ją­cym pra­wem?? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspek­ty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z pra­wem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?. Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?. (źr.: Prawo a wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów ? a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z nich jest egze­kwo­wa­nie usta­lo­nych zasad.

Czytaj dalej… Odpowiedzialność admi­ni­stra­to­ra sys­te­mu”

Sam dostarczyłem sznur, na którym próbowano mnie powiesić

Wpadł mi wła­śnie przed oczy cie­ka­wy wpis na pew­nym blogu:

Historia o tym w jaki spo­sób pra­wie stra­ci­łem fir­mę i sam dostar­czy­łem (bo nawet nie sprze­da­łem) sznur, na któ­rym pró­bo­wa­no mnie powie­sić. [1]

Zanim przej­dę do sed­na, przy­po­mnę jeden z moich artykułów:

Na czym więc pole­ga sku­tecz­ne zarzą­dza­nie? Na zro­zu­mie­niu, posia­da­niu pla­nu dzia­ła­nia i prze­my­śla­nym two­rze­niu ogra­ni­czeń. Robi tak każ­da więk­sza fir­ma: powsta­ją zakre­sy obo­wiąz­ków, wewnętrz­ne zarzą­dze­nia i pro­ce­du­ry. To wszyst­ko to nic inne­go jak ogra­ni­cze­nia. Opracowanie mode­lu orga­ni­za­cji więc, to nie tyl­ko opi­sa­nie pro­ce­sów bo te są jedy­nie efek­tem ist­nie­ją­cych ogra­ni­czeń. Pełny model orga­ni­za­cji, dają­cy zro­zu­mie­nie tego jak ona dzia­ła, to kom­plet­ny model poję­cio­wy ? nazwy i defi­ni­cje pod­sta­wo­wych pojęć opi­su­ją­cych jej dzia­ła­nie (co to jest klient, pro­dukt, kon­tra­hent, ?), spe­cy­fi­ka­cja wszel­kich ogra­ni­czeń czy­li reguł biz­ne­so­wych oraz spe­cy­fi­ka­cji sta­no­wisk i wyma­ga­nych na każ­dym z nich umie­jęt­no­ści (pamię­ta­my, że ogra­ni­cze­niem jest tak­że obo­wią­zu­ją­ce pra­wo). [2]

Kluczem do sku­tecz­ne­go zarzą­dza­nia jest wizja dzia­ła­nia fir­my i zbu­do­wa­nie wewnętrz­nych ogra­ni­czeń, któ­re będą trzy­ma­ły” wszyst­kie zacho­wa­nia pra­cow­ni­ków na wła­ści­wym kur­sie”. 

Bohater tej histo­rii tak pisze o sobie:

W cią­gu 9 lat dzia­łal­no­ści roz­ro­sła się od jed­no­oso­bo­wej fir­my do gru­py ponad 60 pra­cow­ni­ków i przy­cho­dów na pozio­mie 56 mln rocz­nie. Z powo­du bra­ku cza­su na zmia­ny for­my dzia­łal­no­ści przez cały ten okres dzia­ła­ła w for­mie jed­no­oso­bo­wej dzia­łal­no­ści gospo­dar­czej pro­wa­dzo­nej przez Dariusza Kuźniewskiego.

Jak widać, pomysł na biz­nes był dobry bo wła­ści­ciel osią­gnął suk­ces. Jednak, jak pisze w innym miej­scu, nie zmie­nił swo­je­go podej­ścia do zarzą­dza­nia nią:

Nie pomy­śla­łem, że celem tych osób jest tak napraw­dę znisz­cze­nie fir­my, wykra­dze­nie bazy klien­tów, ?prze­ję­cie? klu­czo­wych pra­cow­ni­ków, przy­własz­cze­nie sprzę­tu, pozy­ska­nie ode mnie kapi­ta­łu oraz kil­ka ele­men­tów, któ­re dla dobra przy­szłych postę­po­wań nie mogę teraz wspo­mnieć. […] Nie muszę chy­ba wspo­mi­nać, że wie­le kopii umów 31 lip­ca br. tajem­ni­czo znik­nę­ło z dzia­łu księ­go­wo­ści.

Jedną z metod zarzą­dza­nia ryzy­kiem jest roz­kła­da­nie upraw­nień, tam gdzie ryzy­ko jest duże, jed­na oso­ba nie powin­na mieć moż­li­wo­ści spraw­czych”. W tym miej­scu czę­sto sły­szę, że fir­ma mam być zwin­na a pro­ce­du­ry nie powin­ny stwa­rzać wąskich gar­deł. Ogólnie to praw­da, jed­nak każ­dy obszar fir­my to inne ryzy­ka, i po pro­stu pew­ne rze­czy muszą trwać” (to temat na inny arty­kuł…). Co do zasa­dy archi­wum fir­my powin­no być samo­dziel­nym dzia­łem, nie bio­rą­cym udzia­łu w zawie­ra­niu umów. Dlaczego? Bo jeże­li dostęp do umów ma oso­ba mogą­ca mieć inte­res w ich zagu­bie­niu” lub mody­fi­ka­cji, albo ujaw­nie­niu poza fir­mą, to to się prę­dzej czy póź­niej zdarzy. 

XXX prze­ka­zał mi dys­ki z moni­to­rin­gu oraz z ser­we­ra wewnątrz fir­my, a tak­że klu­cze do maga­zy­nu zewnętrz­ne­go (któ­re miał wyłącz­nie on), gdzie mia­ła być wywie­zio­na księ­go­wość fir­my i zbęd­ne wypo­sa­że­nie. Pojawiła się suge­stia, że nie powi­nie­nem poja­wiać się publicz­nie, bo ?wie­le osób się na mnie szykuje?. […] 

Jakie było moje zdzi­wie­nie, gdy poje­cha­łem do sie­dzi­by fir­my przy XXX w Poznaniu, że: bra­ma jest uchy­lo­na, bocz­ne drzwi nie zamknię­te, nie­włą­czo­ne alar­my, w ser­we­row­ni wyrwa­ne wszyst­kie kable oraz znisz­czo­na kame­ra. W samej fir­mie brak wie­le ele­men­tów wypo­sa­że­nia, nie­któ­re poko­je wywie­zio­ne w pełni.

Nie ma o tym mowy wprost, ale z kon­tek­stu wyni­ka, że naj­praw­do­po­dob­niej wie­lo­mi­lio­no­wy mają­tek fir­my był bez żad­ne­go nad­zo­ru w rękach jed­ne­go pra­cow­ni­ka. A wystar­czy­ło­by, by po pierw­sze były zapa­so­we klu­cze, by było moni­to­ro­wa­ne każ­de otwar­cie i wej­ście do maga­zy­ny, by była pro­ce­du­ra (zestaw reguł) o dopusz­czal­nych godzi­nach otwar­cia maga­zy­nu z reje­stra­cją każ­de­go otwarcia. 

Równocześnie fir­ma XXX zaczę­ła korzy­stać z chro­nio­nej bazy klien­tów kuzniew​ski​.pl i zaczę­ła kon­tak­to­wać się z klien­ta­mi pró­bu­jąc ich prze­jąć naru­sza­jąc przy tym pra­wa klien­tów i łamiąc usta­wę o nie­uczci­wej konkurencji.

To jest to, co zawsze budzi mój uśmiech na twa­rzy, bo prak­tycz­nie pra­cow­ni­cy każ­de­go dzia­łu sprze­da­ży, dla sys­te­mu CRM, zgła­sza­ją wyma­ga­nie by sys­tem CRM pozwa­lał na eks­port danych klien­tów w for­ma­cie excel”. Dostawcy opro­gra­mo­wa­nia reali­zu­ją te wyma­ga­nia (z regu­ły sami są tymi, któ­rzy te wyma­ga­nia zbie­ra­ją) bez zmru­że­nia oka. Ja nie pozwa­lam by wyma­ga­nia dyk­to­wa­li pra­cow­ni­cy (mię­dzy inny­mi chro­niąc fir­my przed tym co powy­żej), a jak już to przede mną zro­bi­li, to wysy­łam natych­miast reko­men­da­cję do Zarządu by takie jak to powy­żej usuwać.

Nonszalancją wie­lu zarządów/właścicieli firm jest to, że godzą się na takie wyma­ga­nia, ja wte­dy sta­ram się prze­ko­ny­wać do rezy­gna­cji z takich nie­bez­piecz­nych funk­cjo­nal­no­ści, bywa­ło że z tego powo­du (mój upór) zerwa­no ze mną umo­wę (cze­go nie żału­ję). Robię to z pro­ste­go powo­du: jeże­li na eta­pie skła­da­nia ofer­ty piszę, że coś tam potra­fię, że mam jakieś doświad­cze­nie, że przed czymś sta­ram się ochro­nić klien­tów, to nie mogę łamać ani wła­snych zasad ani godzić się na to, by na moich oczach i z moją apro­ba­tą klient szedł na dno. To trosz­kę jak lekarz: jeże­li cho­ry pacjent nie reali­zu­je zale­co­nej tera­pii, leka­rzo­wi pozo­sta­je prze­rwać współ­pra­ce z pacjen­tem, bo nie ma pra­wa go do nicze­go zmu­sić ale też nie musi przy­kła­dać ręki do postę­pu­ją­cej cho­ro­by pacjen­ta czy nawet jego zgonu. 

Nie znam tego wła­ści­cie­la fir­my, ale czy­ta­jąc jego emo­cjo­nal­ny (i chy­ba raczej tyl­ko ratu­ją­cy wize­ru­nek) wpis, mam przed ocza­mi wie­le małych i śred­nich firm, któ­re albo mia­ły podob­ne przy­go­dy” albo są dosko­na­ły­mi kan­dy­da­ta­mi na takie. Porzekadło mądry po szko­dzie” to tak­że nie­ste­ty, wie­le histo­rii nie­uda­nych wdro­żeń z powo­dów jak wyżej… Duże fir­my tak­że nie są wol­ne od takich wad…

Na zakoń­cze­nie, przy­po­mnę, że

Problem zaczy­na się gdy takich osób [pra­cow­ni­ków] jest nie jed­na czy kil­ka, a dzie­siąt­ki lub set­ki, w dużych orga­ni­za­cjach poje­dyn­cze tysią­ce. Tu już nie mamy moż­li­wo­ści indy­wi­du­al­ne­go pokie­ro­wa­nia zacho­wa­niem (pra­cą) każ­dej oso­by, udzie­la­nia wska­zó­wek i obser­wa­cji. Owszem, może­my udzie­lić sto­sow­ne­go instruk­ta­rzu każ­dej, to jed­nak wyma­ga dużej dys­cy­pli­ny tego instru­owa­ne­go, jeże­li czu­je on ?wzrok? nad­zor­cy reali­zu­je zada­nia, jeże­li nie, pozo­sta­je wie­rzyć w jego zaan­ga­żo­wa­nie i uczci­wość.[2]

Dlatego

każ­de wdro­że­nie jakie­go­kol­wiek opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie powin­no być poprze­dzo­ne ana­li­zą i opra­co­wa­niem mode­li (opi­su mecha­ni­zmu) dzia­ła­nia fir­my, a nie serią wywia­dów i kolek­cjo­no­wa­niem życzeń pra­cow­ni­ków. Te są z regu­ły przy­czy­ną nie­po­wo­dzeń takich projektów. 

Bibliografia

[2]
J. Zelinski, ?Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć,? Jarosław Żeliński IT-Consulting, 26-Nov-2011. [Online]. Available: https://it-consulting.pl//2011/11/26/reguly-biznesowe-jako-motor-sterujacy-organizacji-fakty-definicje-pojec/. [Accessed: 02-Sep-2017]

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten arty­kuł moż­na czy­tać na dwa spo­so­by: ana­li­ty­cy czy­ta­ją od dechy do dechy po kolei ;). Menedżerowie i tak zwa­ny biz­nes czy­ta­ją od razu koniec, to jest część Na zakoń­cze­nie, gdy uzna­ją, że nie wie­rzą w te wnio­ski (wyrok) to zaczy­na­ją od począt­ku czy­li czy­ta­ją uzasadnienie :).

Niedawno napi­sa­łem:

Pomiędzy poję­cia­mi abs­trak­cja i model jest pew­na klu­czo­wa róż­ni­ca: abs­trak­cja to poję­cie zaś model to opis mecha­ni­zmu, jego kon­struk­cja, dzia­ła­nie, budo­wa. Prosty przy­kład: nazwa­ne pro­sto­ką­ty na typo­wym dia­gra­mie struk­tu­ry orga­ni­za­cyj­nej to abs­trak­cje komó­rek orga­ni­za­cyj­nych i osób w nich zatrud­nio­nych, pro­sto­ką­ty te wraz z linia­mi je łączą­cy­mi sta­no­wią, jako całość, model pod­le­gło­ści zaso­bów w orga­ni­za­cji. (Źródło: Analiza a mode­lo­wa­nie czy­li ile abs­trak­cji a ile rze­czy­wi­sto­ści | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej per­spek­ty­wy powie­my sobie teraz o eta­pach ana­li­zy i pro­jek­to­wa­nia w inży­nie­rii, nie tyl­ko opro­gra­mo­wa­nia, w opar­ciu o MDA ([[Model Driven Architecture]], www​.omg​.org/​mda, pole­cam tak­że poję­cie [[model dri­ven engi­ne­ering]]). Dobra infor­ma­cja dla czy­tel­ni­ków: na koń­cu się wszyst­ko wyja­śni, moż­na pomi­nąć część o MDA 🙂

MDA

Pięć lat temu, jeden z arty­ku­łów o mode­lo­wa­niu i pro­jek­to­wa­niu, koń­czy­łem tymi słowami:

Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

  1. Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (model biz­ne­so­wy) oraz opis tego co ma powstać (opis, wyma­ga­nia na opro­gra­mo­wa­nie). Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
  2. Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: opra­co­wa­niu szcze­gó­łów archi­tek­tu­ry, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne), kodo­wa­niu oraz dostar­cze­niu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biz­ne­su czy­li dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tek­ście wła­śnie na MDA. Czymże to jest? Na stro­nach OMG znaj­dzie­my: Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revi­sed MDA Guide edi­ted in Boston on 18 June 2014 reflects all AB edits requ­ested at the Reston and Boston AB meetings. (Źródło: OMG Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0)

Skorzystam z kil­ku cyta­tów i napi­sze co nie­co o MDA. Poniżej klu­czo­we tezy, nie mia­łem tu ambi­cji lite­ral­ne­go tłu­ma­cze­nia tego doku­men­tu, cho­dzi­ło mi o pryncypia.

This guide descri­bes the Model Driven Architecture (MDA) appro­ach as defi­ned by the Object Management Group (OMG). MDA pro­vi­des an appro­ach for deri­ving value from models and archi­tec­tu­re in sup­port of the full life cyc­le of phy­si­cal, orga­ni­za­tio­nal and I.T. sys­tems (A ?System?, in this con­text, is any arran­ge­ment of parts and the­ir inter­re­la­tion­ships, wor­king toge­ther as a who­le.). The MDA appro­ach repre­sents and sup­ports eve­ry­thing from requ­ire­ments to busi­ness mode­ling to tech­no­lo­gy imple­men­ta­tions. By using MDA models, we are able to bet­ter deal with the com­ple­xi­ty of lar­ge sys­tems and the inte­rac­tion and col­la­bo­ra­tion betwe­en orga­ni­za­tions, people, har­dwa­re, software.

Stosowanie mode­li pozwa­la znacz­nie lepiej radzić sobie ze zło­żo­no­ścią wiel­kich sys­te­mów jaki­mi są orga­ni­za­cje oraz funk­cjo­nu­ją­ce w nich związ­ki mię­dzy ludź­mi, opro­gra­mo­wa­niem i infra­struk­tu­rą. Fakt, że bada­ne orga­ni­za­cje współ­pra­cu­ją z inny­mi, dodat­ko­wo kom­pli­ku­je tę całość.

Models as com­mu­ni­ca­tions vehicles

A fun­da­men­tal value pro­po­si­tion for models and mode­ling is to faci­li­ta­te a team or com­mu­ni­ty coming to a com­mon under­stan­ding and/or consensus.

Jedną z głów­nych ról mode­li, poza ich ana­li­zą, jest komu­ni­ka­cja: komu­ni­ku­je­my innym człon­kom zespo­łu (tak­że klien­tom) to co zro­zu­mie­li­śmy i to cze­go ocze­ku­je­my. Tak więc mode­le są zarów­no opi­sem rze­czy­wi­sto­ści powsta­łym w toku jej zro­zu­mie­nia, są tak­że opi­sem tego co ma powstać, jeże­li chce­my tę rze­czy­wi­stość stworzyć.

[?]Abstraction deals with the con­cepts of under­stan­ding a sys­tem in a more gene­ral way; said in more ope­ra­tio­nal terms, with abs­trac­tion one eli­mi­na­tes cer­ta­in ele­ments from the defi­ned sco­pe; this may result in intro­du­cing a higher level view­po­int at the expen­se of remo­ving deta­il. A model is con­si­de­red more abs­tract if it encom­pas­ses a bro­ader set of sys­tems and less abs­tract if it is more spe­ci­fic to a sin­gle sys­tem or restric­ted set of systems. [?]

Podstawową rze­czą w ana­li­zie jest redu­ko­wa­nie szcze­gó­łów i uogól­nia­nie. Człowiek nie jest w sta­nie ana­li­zo­wać cze­goś co skła­da się z setek detali.

Model Analytics

Once models are cap­tu­red as seman­tic data vario­us ana­ly­tics can be exe­cu­ted across tho­se models inc­lu­ding model vali­da­tion, sta­ti­stics and metrics. Analytics assi­sts in deci­sion making, moni­to­ring and quali­ty asses­sment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele poję­cio­we i ana­li­tycz­ne słu­żą do zro­zu­mie­nia bada­nej rze­czy­wi­sto­ści. Modele two­rzo­ne (pro­jek­to­wa­nie) słu­żą do testo­wa­nia pomy­słów i podej­mo­wa­nia decy­zji, dalej zaś sta­no­wią opis cech wyma­ga­ne­go roz­wią­za­nia. Modele wyko­ny­wal­ne to inne mode­le ale bazu­ją na mode­lach ana­li­tycz­nych. Poniżej, na bazie MOF ([[Meta Object Facility]]), poka­za­no trzy pozio­my abs­trak­cji (poziom zero­wy to rzeczywistość).

poziomy-abstrakcji

Abstrakcja to uprosz­czo­ny” (pozba­wio­ny zbęd­nych szcze­gó­łów) model okre­ślo­nej rze­czy­wi­sto­ści. Metamodel to mecha­nizm two­rze­nia tej rze­czy­wi­sto­ści w tym tak­że model poję­cio­wy (wię­cej w dal­szej części).

Model (M1) więc jest albo wyni­kiem (pro­duk­tem) ana­li­zy bada­nej rze­czy­wi­sto­ści, albo wyni­kiem (pro­duk­tem) pro­ce­su jej pro­jek­to­wa­nia (pro­jek­to­wa­nia rozwiązania). 

Model Simulation and Execution

Models as data can dri­ve simu­la­tion engi­nes that can assist in both ana­ly­tics and exe­cu­tion of the desi­gns cap­tu­red in models. Simulation assi­sts in the human under­stan­ding of how a mode­led sys­tem will func­tion as well as a way to vali­da­te that models are cor­rect. Models can, in some cases be direc­tly exe­cu­ted ? serving as the ?sour­ce code? for high­le­vel appli­ca­tions that imple­ment pro­ces­ses, data repo­si­to­ries and servi­ce end­po­ints. Model exe­cu­tion pro­vi­des a direct and imme­dia­te path to reali­zing a design with a mini­mum of tech­ni­cal deta­ils being expo­sed. DBMS Schema and pro­cess models are well-known cate­go­ries of (par­tial­ly) exe­cu­ta­ble models.[?]

Modele symu­la­cyj­ne słu­żą do testo­wa­nia hipo­tez i podej­mo­wa­ni decy­zji. Modele wyko­ny­wal­ne, w tym two­rzo­ne auto­ma­tycz­nie na bazie mode­li abs­trak­cyj­nych, to narzę­dzia do two­rze­nia wyko­ny­wal­ne­go kodu. Nie tyl­ko w moim mnie­ma­niu, jest to albo dale­ka przy­szłość (mam na myśli komer­cyj­ne zasto­so­wa­nia) albo wyłącz­nie aka­de­mic­kie bada­nia. Wiem, że są uda­ne pró­by gene­ro­wa­nia dzia­ła­ją­ce­go kodu z mode­li, jed­nak wyma­ga­nia na ilość deta­li, jakie trze­ba zade­kla­ro­wać w tych mode­lach, zbli­ża ich zło­żo­ność do zło­żo­no­ści kodu jaki powsta­je. Nie będzie­my się tu zaj­mo­wa­li mode­la­mi wykonywalnymi.

Cztery produkty

Te dwa opi­sa­ne na począt­ku eta­py do ana­li­za sys­te­mo­wa orga­ni­za­cji (potocz­nie ana­li­za biz­ne­so­wa”) oraz imple­men­ta­cja roz­wią­za­nia. Produkty to …

MDA to archi­tek­tu­ra mają­ca trzy pozio­my mode­lo­wa­nia, nazy­wa­ne od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is use­ful to iden­ti­fy par­ti­cu­lar ?lay­ers? of an archi­tec­tu­re with respect to its level of abs­trac­tion. While the­re can be any num­ber of archi­tec­tu­ral lay­ers, a bro­ad cate­go­ri­za­tion of this con­cept is:

  • Business or doma­in models ? models of the actu­al people, pla­ces, things, and laws of a doma­in. The ?instan­ces? of the­se models are ?real things?, not repre­sen­ta­tions of tho­se things in an infor­ma­tion sys­tem. In MDA doma­in models have histo­ri­cal­ly been cal­led a ?CIM? for ?Computation Independent Model?.
  • Logical sys­tem models ? models of the way the com­po­nents of a sys­tem inte­ract with each other, with people and with orga­ni­za­tions to assist an orga­ni­za­tion or com­mu­ni­ty in achie­ving its goals. [model PIM]
  • Implementation models ? the way in which a par­ti­cu­lar sys­tem or sub­sys­tem is imple­men­ted such that it car­ries out its func­tions. Implementation models are typi­cal­ly tied to a par­ti­cu­lar imple­men­ta­tion tech­no­lo­gy or plat­form. [model PSM].

Model CIM opi­su­je ludzi i ich związ­ki, miej­sca, pra­wa rzą­dzą­ce tym wszyst­kim. Ten model opi­su­je real­ną, bada­ną rze­czy­wi­stość cał­ko­wi­cie abs­tra­hu­jąc od wyko­rzy­sty­wa­nych ewen­tu­al­nie posia­da­nych narzę­dzi infor­ma­tycz­nych (w przy­pad­ku start-up’u lub roz­wo­ju orga­ni­za­cji jest to przy­szła jej postać). Nie jest to model jakie­go­kol­wiek opro­gra­mo­wa­nia ani tego jak ono dzia­ła. Produktem tego eta­pu są: mode­le pro­ce­sów biz­ne­so­wych, spe­cy­fi­ka­cja reguł biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć i mode­le pojęciowe.

Model PIM opi­su­je kom­po­nen­ty apli­ka­cji, ich wza­jem­ne inte­rak­cje, logi­kę dzia­ła­nia tych kom­po­nen­tów (ta część logi­ki opi­sa­nej w mode­lu CIM, któ­ra ma być reali­zo­wa­na w apli­ka­cji). Produktem tego eta­pu są mode­le: przy­pad­ków uży­cia (w tym postać nośni­ków danych, moc­ku­p’y ekra­nów), kom­po­nen­tów, wewnętrz­ne struk­tu­ry kom­po­nen­tów (mode­le dzie­dzi­ny z per­spek­ty­wy wzor­ca MVC), inte­rak­cji, inne jeśli konieczne.

Model PSM to model będą­cy pro­jek­tem wyko­naw­czym. Jest to roz­sze­rze­nie mode­lu PIM, uszcze­gó­ło­wie­nie go wraz z dodat­ko­wy­mi ele­men­ta­mi tech­nicz­ny­mi (reali­zu­ją­cy­mi śro­do­wi­sko, bez­pie­czeń­stwo, wyma­ga­ną wydaj­ność itp.). Kod apli­ka­cji to mate­ria­li­za­cja (imple­men­ta­cja) mode­lu PSM. 

Powyższe, to czte­ry pro­duk­ty powsta­ją­ce w tym pro­ce­sie. Dlaczego pisze o dwóch eta­pach? Poniżej wyjaśnienie.

model-driven-architecture-structure

Diagram obra­zu­je produkty/fazy defi­nio­wa­ne jako MDA. Każdy pro­dukt ana­li­zy to okre­ślo­ny zestaw mode­li. Na dia­gra­mie wska­za­no jakich nota­cji uży­wa się w każ­dym z nich (tu bazu­jąc na nota­cjach rodem z OMG). Tu przy­po­mi­nam to co już nie raz pisa­łem: celem jest zro­zu­mie­nie (i two­rze­nia potrzeb­nych w danym przy­pad­ku mode­li) oraz prze­ka­za­ne tej wie­dzy, a nie two­rze­nie jakichś mode­li i doku­men­tów”. Każdy model, jego powsta­nie, ma okre­ślo­ny cel.

Jeszcze sto­sun­ko­wo nie­daw­no w moich pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, wyróż­nia­łem trzy eta­py: ana­li­za orga­ni­za­cji, spe­cy­fi­ka­cja wyma­gań oraz opra­co­wa­nie logi­ki dla dedy­ko­wa­nych kom­po­nen­tów opro­gra­mo­wa­nia. W koń­cu, po kil­ku pro­jek­tach, prze­ko­na­łem się, że ten podział nie dzia­ła”. Dlaczego?

Skoro na eta­pie CIM opra­co­wa­li­śmy mię­dzy inny­mi model logi­ki biz­ne­so­wej dla danej orga­ni­za­cji (w tym regu­ły biz­ne­so­we, słow­nik pojęć) to już ją, te logi­kę, mamy. Okazało się, że ten trze­ci etap” w zasa­dzie jest sztucz­ny, gdyż rze­tel­ne opra­co­wa­nie CIM to tak­że ta” logi­ka. Tu war­to przy­to­czyć diagram:

Swego cza­su pisa­łem tak­że o testo­wa­niu modeli:

W toku dal­szej pra­cy podej­mo­wa­na jest decy­zja o zakre­sie pro­jek­tu. Wskazując to, jakie dzia­ła­nia” ma wspie­rać lub prze­jąć na sie­bie apli­ka­cja (to są wła­śnie przy­pad­ki uży­cia), wska­zu­je­my jaka logi­ka ma być przez tę apli­ka­cję reali­zo­wa­na i kie­dy. Wskazanie zakre­su pro­jek­tu jest więc pierw­szym eta­pem defi­nio­wa­nia logi­ki apli­ka­cji. Jeżeli do tego dodać wie­dzę dzie­dzi­no­wą, np. to któ­re ele­men­ty mogą być współ­dzie­lo­ne a któ­re nie, któ­re powin­ni być cał­ko­wi­cie nie­za­leż­ne itp., powsta­nie tak zwa­ny model dzie­dzi­ny sys­te­mu (logi­ka biz­ne­so­wa i jej struk­tu­ra czy­li archi­tek­tu­ra apli­ka­cji, a kon­kret­nie czę­ści reali­zu­ją­cej logi­kę biznesową).

Na zakończenie

Jak podejść do pla­nów zaku­pu tak­że goto­we­go opro­gra­mo­wa­nia? Czy war­to je pro­jek­to­wać? Oczywiście, że war­to z pro­ste­go powo­du: nie ma zna­cze­nia to, czy przy­szłe opro­gra­mo­wa­nie będzie goto­we czy trze­ba je będzie dopie­ro stwo­rzyć. Ono ma reali­zo­wać taką logi­kę jakiej ocze­ku­je­my. Owszem, jest moż­li­wa decy­zja: sko­ro na ryn­ku nie ma poszu­ki­wa­ne­go pro­duk­tu a stwo­rze­nie dedy­ko­wa­ne­go jest zbyt kosz­tow­ne, to albo rezy­gnu­je­my z zaku­pu albo z okre­ślo­nej logi­ki wewnątrz orga­ni­za­cji. Jednak do pod­ję­cia takiej decy­zji musi­my tę logi­kę znać i mieć udo­ku­men­to­wa­ną (no bo jakoś musi­my ją poka­zać ofe­ren­tom). Ale dostaw­cy opro­gra­mo­wa­nia zawsze ofe­ru­ją ana­li­zę wyma­gań”… To praw­da … A ilu z nich powie, że nie mają Wam nic do zaofe­ro­wa­nia? Ale dedy­ko­wa­ne opro­gra­mo­wa­nie może zapro­jek­to­wać tyl­ko jego wyko­naw­ca”. To dla­cze­go fir­my budow­la­ne nie są dopusz­cza­ne do prac pro­jek­to­wych i architektonicznych?

Dlatego na dia­gra­mie powy­żej, jako moment wybo­ru dostaw­cy opro­gra­mo­wa­nia, wska­za­no ten w któ­rym mamy udo­ku­men­to­wa­ny model logi­ki czy­li PIM. To czy logi­ka taka jest dostęp­na w jakimś pro­duk­cie na ryn­ku czy nie, nie zmie­nia fak­tu, że i tak musi zostać ona opi­sa­na, bez cze­go taki wybór jest nie­moż­li­wy. Czym więc są (czym powin­ny być) wyma­ga­nia na opro­gra­mo­wa­nie? Niestety powin­ny być zwię­złym pro­jek­tem a nie dłu­gą listą cech.

Jeden ana­li­tyk pro­jek­tant mają­cy dobre wspar­cie narzę­dzio­we, jest w sta­nie wyko­nać ana­li­zę i pro­jekt dla dowol­nie dużej fir­my, wystar­czy, że potra­fi two­rzyć abs­trak­cje i zarzą­dzać zło­żo­no­ścią doku­men­ta­cji. Czy kil­ku ana­li­ty­ków zro­bi to nie gorzej i szyb­ciej? Nie znam takie­go przy­pad­ku.… bo im wię­cej osób pro­wa­dzi taką ana­li­zę tym wię­cej pra­cy wyma­ga koor­dy­na­cja i pra­ca nad spój­no­ścią całości.

Na zakoń­cze­nie cytat z pew­nej dyskusji:

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up ?the expe­ri­ment? to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.
2. Our team pro­du­ced more than twi­ce the code of the other teams.
3. Our team achie­ved a 75% reduc­tion in cost.
4. Our team achie­ved a 66% reduc­tion in defect rate.
5. Our team was twi­ce as fast (with half the size).
We have sin­ce got­ten more effi­cient and more advan­ced, so I don?t know what the num­bers are now.
(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
na gotowca”">

Analiza wymagań metodą na gotowca”

Od cza­su do cza­su spo­ty­kam się z ana­li­za­mi wyma­gań, powsta­ły­mi w dość spek­ta­ku­lar­ny spo­sób. Jest to meto­da zbie­ra­nia wyma­gań na pro­ce­sy refe­ren­cyj­ne” i nadal nie­ste­ty ma wzię­cie. Głównym powo­dem jest to, że nie wyma­ga żad­nych umie­jęt­no­ści, może to zro­bić każ­dy. W ostat­nim roku spo­tka­łem się z wyni­ka­mi tego podej­ścia trzy razy. Wszystkie trzy spa­lo­ne nie­ste­ty… Dlaczego?

Jednym z chy­ba naj­bar­dziej zna­nych zesta­wów pro­ce­sów refe­ren­cyj­nych jest APQC. Tak piszą jego pro­mo­to­rzy o nim:

APQC’s Process Classification Framework?(PCF) is the most used pro­cess fra­me­work in the world. It cre­ates a com­mon lan­gu­age for orga­ni­za­tions to com­mu­ni­ca­te and defi­ne work pro­ces­ses com­pre­hen­si­ve­ly and witho­ut redun­dan­cies. Organizations are using it to sup­port bench­mar­king, mana­ge con­tent, and per­form other impor­tant per­for­man­ce mana­ge­ment acti­vi­ties. (Źródło: About APQC)

Co cie­ka­we nie ma tu mowy o wyma­ga­niach. Jednak tego typu spe­cy­fi­ka­cje są uży­wa­ne w cie­ka­wy spo­sób: nazwy tych pro­ce­sów są kolej­no czy­ta­ne a pra­cow­ni­cy fir­my, któ­ra jest bene­fi­cjen­tem tej ana­li­zy”, sie­dzą na sali i w toku warsz­ta­tów wyma­gań” mówią, któ­ry pro­ces wg. nich powi­nien być wyma­ga­ny w sys­te­mie ERP (co by to nie mia­ło zna­czyć), mimo że i tak nie rozu­mie­ją co wybie­ra­ją, bo nie wie­dzą jak dany pro­ces jest reali­zo­wa­ny (spe­cy­fi­ka­cja APQC ope­ru­je ich listą nie mode­la­mi). W efek­cie otrzy­mu­je­my nie raz kil­ka tysię­cy (!) tak zwa­nych wyma­gań”, z któ­ry­mi nie bar­dzo wia­do­mo co zro­bić. Owszem doku­ment, dzie­ło takie­go ana­li­ty­ka”, wyglą­da impo­nu­ją­co. Rzecz w tym, że nie ma tu mowy i jakim­kol­wiek spraw­dze­niu kom­plet­no­ści, nie­sprzecz­no­ści i spój­no­ści (brak mode­li tych pro­ce­sów nie pozwa­la na takie weryfikacje).

Podobna meto­da, sen­sow­niej­sza ale tyl­ko tro­chę, pole­ga na tym, że listą bazo­wą jest nie APQC a lista pro­ce­sów biz­ne­so­wych (a raczej dostęp­nych czyn­no­ści i nazw doku­men­tów) dostar­czo­na z kon­kret­nym opro­gra­mo­wa­niem ERP. Tu przy­naj­mniej wie­my, że to opro­gra­mo­wa­nie ma te cechy, ale nadal jest to tyl­ko ich lista. Niektóre fir­my, pro­du­cen­ci opro­gra­mo­wa­nia ERP, dostar­cza­ją spe­cjal­ne narzę­dzie, któ­re panu­je nad spój­no­ścią takie­go wybo­ru. Ma np. wbu­do­wa­ne infor­ma­cje o wza­jem­nych powią­za­niach pomię­dzy pro­ce­sa­mi i ich pro­duk­ta­mi (np. powią­za­nie zamó­wień z fak­tu­ra­mi) co pozwa­la unik­nąć sytu­acji rezy­gna­cji z doku­men­tów źró­dło­wych i żąda­niu tych, któ­re na ich pod­sta­wie powsta­ją. Jednak uży­cie tego narzę­dzia wyma­ga posia­da­nia wie­dzy o pro­ce­sach biz­ne­so­wych w danej fir­mie, bo to zesta­wie­nie pro­ce­sów w sys­te­mie ERP nie słu­ży do gło­so­wa­nia chcę/nie chcę”, to zesta­wie­nie słu­ży do wyko­na­nia tak zwa­nej ana­li­zy gap/fit (nie ma/jest), czy­li do wykry­cia pro­ce­sów, któ­rych nie ma na tej liście, a w toku ana­li­zy biz­ne­so­wej klien­ta stwier­dzo­no, że są reali­zo­wa­ne. Oczywiście, dla takie­go porów­na­nia, bar­dzo istot­na jest wie­dza o tym jak dany pro­ces prze­bie­ga w bada­nej fir­mie i w ofe­ro­wa­nym (pla­no­wa­nym do wdro­że­nia) opro­gra­mo­wa­niu ERP. Nie zmie­nia to fak­tu, że dostaw­cy opro­gra­mo­wa­nia ERP, nie wie­dzieć cze­mu, bar­dzo czę­sto nie sto­su­ją się do tych zale­ceń, zale­ceń pro­du­cen­tów tego co ofe­ru­ją i wdra­ża­ją. Warto pamię­tać, że

pod­pi­sa­nie umo­wy z dostaw­cą ERP przed wyko­na­niem tej ana­li­zy czę­sto rodzi poważ­ny pro­blem: odkry­cie” (ana­li­za gap/fit), że to kon­kret­ne opro­gra­mo­wa­nie nam po pro­tu nie pasu­je (wykry­ta w toku gap/fit luka jest duża), i skut­ku­je dość pokaź­ną listą tak zwa­nych kasto­mi­za­cji”. Deklaracja dostaw­cy ERP: nasze opro­gra­mo­wa­nie Wam pasu­je” skła­da­ne przed wyko­na­niem takiej ana­li­zy, to niczym nie popar­te wró­że­nie z fusów. 

Warto też pamię­tać, że

sama nazwa pro­ce­su to za mało, bo np. wysta­wie­nie fak­tu­ry sprze­da­ży na praw­dę może prze­bie­gać na wie­le spo­so­bów i uzna­nie, na pod­sta­wie samej tyl­ko nazwy pro­ce­su, że to wyma­ga­nie speł­nia­my” jest raczej poważ­nym nad­uży­ciem. Przebieg pro­ce­sów biz­ne­so­wych i orga­ni­za­cja pra­cy w każ­dej fir­mie, są efek­tem wie­lu bar­dzo zło­żo­nych zależ­no­ści, kom­pe­ten­cji i umie­jęt­no­ści ludzi oraz narzę­dzi pra­cy jakich używają.

Trzy lata temu pisałem:

Na pew­nym wyso­kim pozio­mie abs­trak­cji moż­na mówić o pro­ce­sach refe­ren­cyj­nych, a raczej dobrych prak­ty­kach np. pro­ces two­rze­nia nowe­go pro­duk­tu powi­nien mieć nastę­pu­ją­ce kro­ki: opis pomy­słu, ana­li­za SWOT pro­duk­tu na ryn­ku, osza­co­wa­nie ceny sprze­da­ży, kosz­tu wytwa­rza­nia i pla­no­wa­ne­go pozio­mu sprze­da­ży, pro­gno­za prze­pły­wów gotów­ko­wych. Ale to ?ogól­ny opis? a nie ?pro­to­ty­py pro­ce­sów i mapy pro­ce­sów?. pro­ces i jego mapa to naj­niż­szy, imple­men­ta­cyj­ny poziom opisu.Tak więc są na pew­no pew­ne pryn­cy­pia, moż­na je zna­leźć np. w książ­ce M.E.Portera ?Strategie kon­ku­ren­cji? (autor kon­cep­cji ryn­ko­we­go łań­cu­cha war­to­ści) czy P.Druckera ?Praktyka zarzą­dza­nia?. Jednak jak nam ktoś ofe­ru­je sys­tem ERP z ?wbu­do­wa­ny­mi pro­ce­sa­mi refe­ren­cyj­ny­mi? to nale­ży rozu­mieć: ?szy­ku­je się total­na rewo­lu­cja?, czy ją prze­ży­je­my? (Źródło: Procesy refe­ren­cyj­ne czy­li kto żyw niech ucie­ka | Jarosław Żeliński IT-Consulting)

Wszystkie te trzy spo­tka­ne przy­pad­ki tak wyko­na­nej ana­li­zy, nie­ste­ty skoń­czy­ły klę­ską: w jed­nym na szczę­ście od razu odrzu­co­no wyni­ki ana­li­zy więc stra­ta była rela­tyw­nie mała. Więc jeże­li ktoś Państwu ofe­ru­je pro­sty spo­sób na wyko­na­nie ana­li­zy wyma­gań” na, bądź co bądź, bar­dzo zło­żo­ny sys­tem infor­ma­tycz­ny, to zasta­nów­cie się nad ryzy­kiem jakie podejmujecie…