RODO – blaski i cienie

1Poprzedni arty­kuł o RODO koń­czył się słowami:

Co przed nami? W RODO np. czy­ta­my, że ?Ochrona osób fizycz­nych w związ­ku z prze­twa­rza­niem danych oso­bo­wych jest jed­nym z praw pod­sta­wo­wych. Art. 8 ust. 1 Karty praw pod­sta­wo­wych Unii Europejskiej? ale już trzy aka­pi­ty dalej czy­ta­my, że ?Prawo do ochro­ny danych oso­bo­wych nie jest pra­wem bez­względ­nym;?, więc mamy to pra­wo czy go nie mamy? Dokument Rozporządzenie 2016/679 o ochro­nie danych oso­bo­wych (RODO) ROZPORZĄDZENIE PARLAMENTU EUROPEJSKIEGO I RADY (UE) 2016/679 z dnia 27 kwiet­nia 2016 r. w spra­wie ochro­ny osób fizycz­nych w związ­ku z prze­twa­rza­niem danych oso­bo­wych i w spra­wie swo­bod­ne­go prze­pły­wu takich danych oraz uchy­le­nia dyrek­ty­wy 95/46/WE w znacz­nej mie­rze sta­no­wi sobą listę enu­me­ra­tyw­nie wyszcze­gól­nio­nych przy­pad­ków prze­twa­rza­nia danych i ich ochro­ny, sto­so­wa­nie tego pra­wa będzie bar­dzo trud­ne. (źr. : RODO Ochrona danych oso­bo­wych czy­li ochro­na cze­go? Cz. I | | Jarosław Żeliński IT-Consulting)

Zapowiadałem kon­ty­nu­ację i jest oka­zja. Na stro­nach Polskiego Towarzystwa Informatycznego zosta­ła udo­stęp­nio­na pre­zen­ta­cja Pana Wojciecha Wiewiórowskiego2. Zawiera zebra­ne klu­czo­we infor­ma­cje na temat danych oso­bo­wych, ich ochro­ny i oce­ny któ­re i kie­dy są (powin­ny być) chro­nio­ne. Biorąc pod uwa­gę wie­dzę auto­ra i obszer­ność tej pre­zen­ta­cji, uży­łem tego mate­ria­łu jako aktu­al­ne­go sta­nu wie­dzy o reali­zo­wa­nych i pla­no­wa­nych dzia­ła­niach na temat ochro­ny danych osobowych.

Dziedzinowy model rzeczywistości RODO3

Zanim zacznie­my opi­sy­wa­nie prze­wi­dy­wa­nych moż­li­wych skut­ków wpro­wa­dza­nych norm praw­nych, zbu­du­je­my model poję­cio­wy dzie­dzi­ny, któ­rej te nor­my doty­czą oraz model struk­tu­ry tego cze­go doty­czą te nor­my. Jest to waż­ne, bo do ana­li­zy potrze­bu­je­my odpo­wied­nie­go narzę­dzia (meto­dy) a tak­że dla­te­go, że chcę w tych nor­mach wska­zać ele­men­ty tak zwa­ne­go myśle­nia życze­nio­we­go4. Ten typ myśle­nia jest szcze­gól­nie groź­ny u ustawodawcy.

Opisywałem już tu model wyja­śnia­ją­cy poję­cio­we kwe­stie fak­tów i danych, któ­ry wyglą­da tak:

Kluczowe są tu poję­cia: dane i nośnik danych. Istotne jest tak­że to, że dane są zawsze zwią­za­ne z jakimś nośni­kiem, bez któ­re­go nie są w sta­nie ist­nieć. Nieco inne poję­cia są zwią­za­ne z powsta­wa­niem tych danych. Kontekstowym uzu­peł­nie­niem powyż­sze­go mode­lu są poję­cia zwią­za­ne z tym, gdzie powsta­ją fak­ty zwią­za­ne z pod­mio­tem, oraz któ­re jego cechy są cecha­mi iden­ty­fi­ku­ją­cy­mi (i co to znaczy).

Dane to infor­ma­cje opi­su­ją­ce fak­ty zwią­za­ne z okre­ślo­nym pod­mio­tem, cechy tego pod­mio­tu to tak­że infor­ma­cje (dane opi­su­ją­ce pod­miot). Zwracam tu uwa­gę, że dane opi­su­ją­ce pod­miot (jego cechy) i dane o pod­mio­cie (o tym co się zda­rzy­ło w związ­ku z nim) to odręb­ne typy infor­ma­cji. Cechy pod­mio­tu są z nim trwa­le zwią­za­ne, cha­rak­te­ry­zu­ją go. Fakty zwią­za­ne z pod­mio­tem mogą zacho­dzić od tego pod­mio­tu cał­ko­wi­cie nie­za­leż­ne, np. potrą­ce­nie prze­chod­nia przez samo­chód to fakt z nim zwią­za­ny, doty­czy potrą­co­ne­go ale tak­że kie­row­cy samochodu.

Powyższe, to mode­le poję­cio­we, czy­li poję­cia i syn­tak­tycz­ne związ­ki mię­dzy nimi (nie są to onto­lo­gie!). Związek syn­tak­tycz­ny to po pro­stu coś co zaist­nia­ło (mogło zaist­nieć) powo­du­jąc, że dane poję­cia są (mogą być) z sobą koja­rzo­ne. Pamiętajmy tak­że, że dane to zna­ki na nośni­ku, infor­ma­cje to treść tak zapi­sa­na. Tylko czło­wiek rozu­mie treść, kom­pu­ter nie.

Brakuje nam już tyl­ko struk­tu­ry danych i nośni­ków, na jakich są zapi­sa­ne, oraz związ­ków mię­dzy nimi. Poniżej model przed­sta­wia­ją­cy dane opi­su­ją­ce pod­mio­ty, dane opi­su­ją­ce zacho­dzą­ce fak­ty oraz dane wska­zu­ją­ce na zwią­zek fak­tu z pod­mio­tem. Np. fak­tem jest lot samo­lo­tu, pod­mio­tem jest oso­ba, imien­ny bilet to dane wska­zu­ją­ce na zwią­zek danej oso­by z kon­kret­nym lotem czy­li dane łączą­ce fakt z podmiotem.

Tu waż­na infor­ma­cja: dane łączą­ce opis fak­tu z opi­sem pod­mio­tu mogą powstać w ramach zamie­rzo­ne­go aktu jakim jest np. wysta­wie­nie imien­ne­go bile­tu na kon­kret­ny prze­lot. Mogą też jed­nak powstać w wyni­ku deduk­cji, na pod­sta­wie innych danych, np. na zdję­ciu kabi­ny samo­lo­tu moż­na wska­zać twarz kon­kret­ne­go pasa­że­ra, twarz oso­by jest uni­kal­na i pozwa­la poznać jej dane (dotrzeć do niej) o ile mamy dostęp do danych zawie­ra­ją­cych twa­rze i dane osób (pod­miot). Dedukcją jest tu wnio­sko­wa­nie: jeże­li zna­my wize­ru­nek oso­by X i wie­my, że taki sam wize­ru­nek poja­wił się w w kon­kret­nym cza­sie w samo­lo­cie Y to zna­czy, że oso­ba X była w samo­lo­cie Y w tym kon­kret­nym cza­sie. Tak więc infor­ma­cję zapi­sa­ną na bile­cie tej oso­by (kto leciał i jaki to był lot) jeste­śmy w sta­nie uzy­skać z inne­go źró­dła, pośred­nie­go. Nie zmie­nia to tego, że fakt ten miał miejsce.

Mamy więc model pozwa­la­ją­cy pro­gno­zo­wać skut­ki prób inter­pre­ta­cji wpro­wa­dza­nych norm w obsza­rze danych osobowych.

Tu przy­po­mnę tyl­ko, że model poję­cio­wy (prze­strzeń pojęć) słu­ży do nada­wa­nia nazw ele­men­tom struk­tu­ry. Całość gwa­ran­tu­je jed­no­znacz­ność mode­lu (tu struk­tu­ra opi­sa­na z uży­ciem nota­cji UML, mode­le poję­cio­we to dia­gra­my fak­tów nota­cji SBVR, moż­na je two­rzyć tak­że z uży­ciem dia­gra­mów klas UML).

Należy tu dodać, że pew­ne regu­ły są kon­se­kwen­cją tego, że ope­ru­je­my fak­ta­mi. Fakty to coś co zaszło, a więc są powią­za­ne z upły­wem cza­su, one same i ich skut­ki są więc nie­od­wra­cal­ne. To bar­dzo istot­ne z per­spek­ty­wy wspo­mnia­ne­go wyżej życze­nio­we­go myśle­nia, o czym będzie jesz­cze mowa.

Kolejnym istot­nym ele­men­tem jest tu zna­cze­nie poję­cia posia­dać coś. Kłopoty z potocz­nym poj­mo­wa­niem tego poję­cia dobrze ilu­stru­je poniż­sza aneg­do­ta (nie znam autora):

  1. jeże­li dwie oso­by posia­da­ją po jed­nym jabł­ku i się nimi wymie­nią, nadal posia­da­ją po jed­nym jabłku,
  2. jeże­li dwie oso­by posia­da­ją po jed­nym pomy­śle i się nimi wymie­nią, teraz posia­da­ją po dwa pomysły,
  3. jeże­li dwie oso­by posia­da­ją po jed­nym sekre­cie i się nimi wymie­nią, nie posia­da­ją już sekretów.

Pojęcie posia­dać coś” jest potocz­nie utoż­sa­mia­ne z poję­ciem mieć coś. W pra­wie poję­cie posia­da­nia ozna­cza pra­wo dys­po­no­wa­nia (wła­da­nia), w tym mie­ści się tak­że ogra­ni­cza­nie dostę­pu. W przy­pad­ku przed­mio­tu mate­rial­ne­go potocz­ne rozu­mie­nie nie kłó­ci się z praw­nym, przy­kła­dem jest powyż­sze jabł­ko: przed i po zamia­nie mam jed­no jabł­ko. Jednak pomysł jest tre­ścią, opi­sem któ­ry mamy w naszym umy­śle lub utrwa­li­my np. na papie­rze jako dane. Sekret to nic inne­go jak treść trzy­ma­na w tajem­ni­cy przed inny­mi, jej wyja­wie­nie innym spo­wo­du­je, że prze­sta­nie ona już być sekre­tem. Tym sekre­tem może być, mię­dzy inny­mi, ów pomysł. Jak rozu­mieć powyż­sze trzy fakty?

  1. oso­by mają­ce po jed­nym jabł­ku, po wymia­nie nadal mają po jed­nym jabł­ku: mają jed­nak już inne ich egzemplarze,
  2. oso­by, któ­re wymie­nią się pomy­sła­mi, mają każ­da po dwa pomy­sły, bo nie da się pozbyć raz pozy­ska­nej wie­dzy (czy­li infor­ma­cji o pomyśle),
  3. oso­by, któ­re wymie­nią się sekre­ta­mi (ich tre­ścią), tak na praw­dę wyja­wia­ją infor­ma­cję, sekre­ty prze­sta­ją więc być sekretami.

I tu poja­wia się bar­dzo waż­ne poję­cie: egzem­plarz. Dotyczy ono wyłącz­nie bytów mate­rial­nych: infor­ma­cje nie mają egzem­pla­rzy, bo treść (to co zro­zu­miał czło­wiek) jest z zasa­dy nie­ma­te­rial­na. Tak więc wymia­na jabłek to wymia­na mate­rial­nych przed­mio­tów, odda­jąc jabł­ko tra­ci­my je (prze­sta­je­my je mieć). Wymiana infor­ma­cji pro­wa­dzi wyłącz­nie do powięk­sze­nia sta­nu wie­dzy, udo­stęp­nia­jąc infor­ma­cje nie tra­ci­my już posia­da­nych, pozy­sku­je­my zaś nowe. Prawa mate­rial­ne do tre­ści (np. autor­skie pra­wa mająt­ko­we) to pra­wo dys­po­no­wa­nia nią, a kon­kret­nie pra­wo do ogra­ni­cza­nia korzy­sta­nia z tej tre­ści, ale nie ma fizycz­nej moż­li­wo­ści ode­bra­nia komuś tego, cze­go się już raz dowie­dział, co dobrze ilu­stru­je porze­ka­dło: jak coś zoba­czysz to już nie da się tego odzobaczyć.

RODO

Zajrzyjmy teraz do zbio­ru infor­ma­cji we wspo­mnia­nym mate­ria­le Pana Wiewiórowskiego (2018_05_29_wiewiorowski_PTI. pre­zen­ta­cja zaczy­na się od zdania:

Każdy ma pra­wo do ochro­ny życia pry­wat­ne­go, rodzin­ne­go, czci i dobre­go imie­nia oraz do decy­do­wa­nia o swo­im życiu osobistym.

Co zna­czy powyż­sze? To co potocz­nie nazy­wa­my życiem pry­wat­nym i rodzin­nym to fak­ty z naszej prze­strze­ni pry­wat­nej (oso­bi­ste) lub chro­nio­nej (rodzin­ne). Nie pod­le­ga­ją jed­nak żad­nej ochro­nie – fizycz­nie nie ma takiej moż­li­wo­ści – fak­ty z prze­strze­ni publicz­nej: są z zasa­dy publicz­ne. Czym tak na praw­dę jest tu nasza cześć i dobre imię? To fak­ty o nas, ale infor­ma­cje stwa­rza­my albo my sami albo kłam­cy o nas (o tym czy infor­ma­cja jest praw­dą czy nie, napi­szę pod koniec). Czym jest ochro­na naszych czci i imie­nia? To wyłącz­nie prze­ciw­dzia­ła­nie roz­po­wszech­nia­niu kłamstw na nasz temat. Życie oso­bi­ste i to jak się ono toczy, zale­ży w głów­nej mie­rze od nas samych, cza­sa­mi jed­nak ogra­ni­czo­ne jest pra­wem, np. to jak trak­tu­je­my człon­ków naszej rodzi­ny (prze­moc w rodzinie).

Autor przy­ta­cza tak­że Art. 51 Konstytucji RP:

  1. Nikt nie może być obo­wią­za­ny ina­czej niż na pod­sta­wie usta­wy do ujaw­nia­nia infor­ma­cji doty­czą­cych jego osoby.
  2. Władze publicz­ne nie mogą pozy­ski­wać, gro­ma­dzić i udo­stęp­niać innych infor­ma­cji o oby­wa­te­lach niż nie­zbęd­ne w demo­kra­tycz­nym pań­stwie prawnym.
  3. Każdy ma pra­wo dostę­pu do doty­czą­cych go urzę­do­wych doku­men­tów i zbio­rów danych. Ograniczenie tego pra­wa może okre­ślić ustawa.
  4. Każdy ma pra­wo do żąda­nia spro­sto­wa­nia oraz usu­nię­cia infor­ma­cji nie­praw­dzi­wych, nie­peł­nych lub zebra­nych w spo­sób sprzecz­ny z ustawą.
  5. Zasady i tryb gro­ma­dze­nia oraz udo­stęp­nia­nia infor­ma­cji okre­śla ustawa.

Łatwo zauwa­żyć, że żaden prze­pis nie koli­du­je z tym co opi­su­je wyżej opi­sa­ny model. Ale już na kolej­nej stro­nie 7 mate­ria­łu mamy Artykuł 16 Traktatu o funk­cjo­no­wa­niu UE:

  1. Każda oso­ba ma pra­wo do ochro­ny danych oso­bo­wych jej dotyczących.
  2. Parlament Europejski i Rada, sta­no­wiąc zasa­dy doty­czą­ce ochro­ny osób fizycz­nych w zakre­sie prze­twa­rza­nia danych oso­bo­wych przez insty­tu­cje, orga­ny i jed­nost­ki orga­ni­za­cyj­ne Unii oraz przez Państwa Członkowskie w wyko­ny­wa­niu dzia­łań wcho­dzą­cych w zakres zasto­so­wa­nia pra­wa Unii, a tak­że zasa­dy doty­czą­ce swo­bod­ne­go prze­pły­wu takich danych. Przestrzeganie tych zasad pod­le­ga kon­tro­li nie­za­leż­nych organów.

Jeżeli pod poję­ciem ochro­ny mamy na myśli nie­ujaw­nia­nie nie­ujaw­nio­ne­go (sekret) to jest to moż­li­we. Jeżeli mamy na myśli ochro­nę w rodza­ju ogra­ni­cza­nia dostę­pu do infor­ma­cji począt­ko­wo jaw­nych, to nie­ste­ty jest to już życze­nio­wość, bo z zasa­dy fak­ty z nami zwią­za­ne, zacho­dzą­ce w prze­strze­ni publicz­nej, nie są chro­nio­ne (każ­dy może być ich świad­kiem). Drugi punkt zawie­ra poję­cia prze­twa­rza­nia i tu jest pro­blem, bo prze­cho­wy­wa­nie zosta­ło w prze­pi­sach zrów­na­ne z prze­twa­rza­niem. Przechowywanie danych to ich utrwa­le­nie na okre­ślo­nym nośni­ku, ale nie ozna­cza ono, że te dane są udo­stęp­nia­ne czy prze­kształ­ca­ne, czy­li prze­twa­rza­ne, w zna­cze­niu jakie i potocz­nie i wg. słow­ni­ka języ­ka pol­skie­go, nada­je­my temu poję­ciu. Osoba posia­da­ją­ca nośnik z dany­mi może nie mieć moż­li­wo­ści ich odczy­ta­nia (zapo­zna­nia się z dany­mi i prze­kształ­ca­nia ich w jaki­kol­wiek spo­sób). Zwróćmy uwa­gę na fakt, że każ­dy kom­pu­ter to opro­gra­mo­wa­nie i zapa­mię­ta­ne dane, co powo­du­je, że mimo ist­nie­nia mecha­ni­zmów kon­tro­li dostę­pu do danych, czy­ni z każ­de­go jego użyt­kow­ni­ka oso­bę prze­twa­rza­ją­cą dane, co jest absurdem.

Kolejne zagad­nie­nie to poję­cie pry­wat­no­ści. Sł. języ­ka pol­skie­go: pry­wat­ny czy­li doty­czą­cy czy­ichś spraw oso­bi­stych i rodzin­nych. Jest to jed­nak sze­ro­ka i potocz­na defi­ni­cja. Czy spra­wą oso­bi­stą jest kłót­nia z człon­kiem rodzi­ny na środ­ku ryn­ku? Opisany wcze­śniej model jasno wska­zu­je, że fak­ty zacho­dzą­ce w prze­strze­ni publicz­nej są publicz­ne, i nie ma już zna­cze­nia cze­go doty­czą, bo to coś zaist­nia­ło w prze­strze­ni publicz­nej. Jeżeli to doty­czy­ło (było zwią­za­ne z) spra­wy oso­bi­stej czy rodzin­nej, nie zmie­nia już nicze­go. Pan Wiewiórowski przy­wo­łu­je arty­kuł pew­ne­go praw­ni­ka opu­bli­ko­wa­ny w USA w 1890, w pod­su­mo­wa­niu jego autor powo­łu­je się na uzna­wa­ne pra­wo” natu­ral­ne (!) mówią­ce, że dom był zawsze nie­do­stęp­nym zam­kiem męż­czy­zny (The com­mon law has always reco­gni­zed a man’s house as his castle, impre­gna­ble, often, even to his own offi­cers enga­ged in the exe­cu­tion of its com­mand.). Czy na pew­no jest to dobra dro­ga? Owszem dom, rozu­mia­ny jako prze­strzeń chro­nio­na, to miej­sce gdzie nie powsta­ją fak­ty publicz­ne. Jeżeli isto­tą tego prze­ka­zu jest to, by publi­ko­wa­nie zdjęć wyko­na­nych w domu było poten­cjal­nie karal­ne, to jest to ogól­nie słusz­ne, jed­nak nie brnął bym w stro­nę bez­względ­nej ochro­ny, bo zabrnie­my w ochro­nę prze­mo­cy domo­wej, o ile tyl­ko docho­dzi do niej w zam­ku mężczyzny”.

Pojęcie pry­wat­no­ści, w moich oczach zosta­ło już dość poważ­nie wypa­czo­ne. Na stro­nie 10 mate­ria­łu, przy­to­czo­no kil­ka defi­ni­cji pry­wat­no­ści, cie­ka­we jest to, że wszyst­kie one zasa­dza­ją się na pra­wie do zbie­ra­nia i prze­twa­rza­nia infor­ma­cji i nic nie mówią o tym, w jakich warun­kach powsta­ły (patrz model poję­cio­wy wyżej). Prowadzi to do absur­du jakim jest uzna­nie, że ja mam pra­wo decy­do­wać o tym, co ktoś inny robi z dany­mi o fak­tach mnie doty­czą­cych, jakie zaszły w prze­strze­ni publicz­nej. Jest to kla­sycz­ne życze­nio­we myśle­nie. Tak więc mówie­nie o pry­wat­no­ści, defi­niu­jąc ją tyl­ko jako coś co doty­czy oso­by, pro­wa­dzi do absur­dów takich jak uzna­nie za moją rzecz pry­wat­ną tego, że pośli­zgną­łem się i wywi­ną­łem orła na środ­ku ulicy.

Kolejna kwe­stia to poję­cie danych oso­bo­wych. RODO (Art. 4. Definicje):

1) ?dane oso­bo­we? ozna­cza­ją infor­ma­cje o ziden­ty­fi­ko­wa­nej lub moż­li­wej do ziden­ty­fi­ko­wa­nia oso­bie fizycz­nej (?oso­bie, któ­rej dane doty­czą?); moż­li­wa do ziden­ty­fi­ko­wa­nia oso­ba fizycz­na to oso­ba, któ­rą moż­na bez­po­śred­nio lub pośred­nio ziden­ty­fi­ko­wać, w szcze­gól­no­ści na pod­sta­wie iden­ty­fi­ka­to­ra takie­go jak imię i nazwi­sko, numer iden­ty­fi­ka­cyj­ny, dane o loka­li­za­cji, iden­ty­fi­ka­tor inter­ne­to­wy lub jeden bądź kil­ka szcze­gól­nych czyn­ni­ków okre­śla­ją­cych fizycz­ną, fizjo­lo­gicz­ną, gene­tycz­ną, psy­chicz­ną, eko­no­micz­ną, kul­tu­ro­wą lub spo­łecz­ną toż­sa­mość oso­by fizycznej;
2) ?prze­twa­rza­nie? ozna­cza ope­ra­cję lub zestaw ope­ra­cji wyko­ny­wa­nych na danych oso­bo­wych lub zesta­wach danych oso­bo­wych w spo­sób zauto­ma­ty­zo­wa­ny lub nie­zau­to­ma­ty­zo­wa­ny, taką jak zbie­ra­nie, utrwa­la­nie, orga­ni­zo­wa­nie, porząd­ko­wa­nie, prze­cho­wy­wa­nie, adap­to­wa­nie lub mody­fi­ko­wa­nie, pobie­ra­nie, prze­glą­da­nie, wyko­rzy­sty­wa­nie, ujaw­nia­nie poprzez prze­sła­nie, roz­po­wszech­nia­nie lub inne­go rodza­ju udo­stęp­nia­nie, dopa­so­wy­wa­nie lub łącze­nie, ogra­ni­cza­nie, usu­wa­nie lub niszczenie;

Innymi sło­wy dane oso­bo­we to uni­kal­ne cechy lub zestaw cech, danej oso­by. Jednak uzna­nie, że prze­cho­wy­wa­nie jest prze­twa­rza­niem, czy­li zrów­na­nie utrwa­la­nia danych z ich czy­ta­niem, mody­fi­ko­wa­niem i nisz­cze­niem, zno­wu pro­wa­dzi do absur­dów jakie opi­sa­łem już wyżej. Bo jak rozu­mieć takie fak­ty: zapi­sa­nie danych na CDROM, prze­no­sze­nie tego CDROM w tecz­ce, znisz­cze­nie CDROM w nisz­czar­ce mimo tego, że oso­ba wła­da­ją­ca tym CDROM ich nie czy­ta­ła czy­li nie posia­dła infor­ma­cji tam utrwalonych?

Temat sztucz­nej inte­li­gen­cji (AI) cał­ko­wi­cie pomi­jam, jak na razie AI to nic inne­go jak mniej lub bar­dziej wyra­fi­no­wa­ne, deter­mi­ni­stycz­ne sys­te­my podej­mo­wa­nia decy­zji. AI nie jest pod­mio­tem prawa.

Temat tak zwa­ne­go pro­fi­lo­wa­nia to temat na inny arty­kuł. Dużo szu­mu poja­wi­ło się na ten temat po ostat­nich wybo­rach pre­zy­denc­kich w USA i domnie­ma­nym wpły­wie prze­twa­rza­nia danych oso­bo­wych na dobór i adre­so­wa­nie haseł wybor­czych. Przypomnę tyl­ko wcze­śniej­szą uwa­gę: pew­ne dane mogą być two­rzo­ne dro­gą deduk­cji z pozna­nych już fak­tów i dywa­ga­cje na temat tego czy tej deduk­cji zabro­nić (i jak) uwa­żam tak­że za myśle­nie życze­nio­we.

Podsumowanie

Jak poka­za­łem, defi­ni­cje uży­te w usta­wie oraz nor­my powsta­łe z uży­ciem tych defi­ni­cji, nie­jed­no­krot­nie mają cha­rak­ter życze­nio­wy i nie raz bar­dzo repre­syj­ny. Świat fizycz­ny jest taki jaki jest i nie mamy na nie­go wpły­wu. Poszerzanie defi­ni­cji w spo­sób pro­wa­dzą­cy do koli­zji z ich desy­gna­ta­mi (fak­tycz­nym sta­nem tego co defi­niu­ją) i two­rze­nie norm z uży­ciem pojęć mają­cych takie defi­ni­cje, pro­wa­dzi do wie­lu pro­ble­mów z inter­pre­ta­cją tych norm. Do tego docho­dzi kla­sycz­na życze­nio­wość w rodza­ju: pro­szę mi nie robić zdję­cia na uli­cy. Zrównanie pojęć utrwa­la­nia i prze­twa­rza­nia to w moich oczach prze­my­co­ne życze­nie posia­da­nia pra­wa do żąda­nia usu­wa­nia np. nie­wy­god­nych danych na swój temat. Zwieńczeniem tego absur­du jest życze­nio­we Prawo do zapo­mnie­nia5. Bo nawet jeże­li doszło do opu­bli­ko­wa­nia fał­szy­wych infor­ma­cji to mle­ko się wyla­ło”. Coś co nazwę zacie­ra­niem śla­dów, ma sens o ile nie czy­ni­my z tego pra­wa, czy­li cze­goś co nam się bez­względ­nie nale­ży. Tak zwa­ne fej­ki w Internecie sta­ły się powszech­ne, ich usu­wa­nie jest jak naj­bar­dziej potrzeb­ne i moż­li­we, ale już teza, że ktoś ma pra­wo żąda­nia usu­nię­cia WSZYSTKICH, jest co naj­mniej życze­niem, fizycz­nie nie­moż­li­wym. Przetwarzanie to nie tyl­ko nośni­ki elek­tro­nicz­ne na cen­tral­nych ser­we­rach, to tak­że ogrom­ne ilo­ści wydru­ko­wa­nych i roz­dy­stry­bu­owa­nych na papie­rze tek­stów i zdjęć, jak je wszyst­kie usu­nąć? Moim zda­niem wła­ściw­sze jest fran­cu­skie podej­ście, czy­li wpro­wa­dze­nie do pra­wa obo­wiąz­ku umiesz­cza­nia w pod­pi­sach zdjęć fak­tu ich ewen­tu­al­ne­go retuszu.

Niestety nie mogłem być obec­ny na pre­zen­ta­cji zor­ga­ni­zo­wa­nej przez PTI. Jednak treść pli­ku z pre­zen­ta­cją Pana Wiewiórowskiego zawie­ra ogrom­ną ilość zebra­nych, war­to­ścio­wych infor­ma­cji i do niej się odno­si­łem. Myślę, że będzie­my się bory­kać z dużą ilo­ścią pro­ble­mów inter­pre­ta­cyj­nych, któ­rych roz­strzy­ga­nie będzie zapew­ne nie raz uzna­nio­we. Starałem się poka­zać, że two­rze­nie norm praw­nych na bazie nie­pre­cy­zyj­nych pojęć, norm koli­du­ją­cych cza­sa­mi z pra­wa­mi przy­ro­dy, pro­wa­dzi do powsta­wa­nia złe­go pra­wa. Najbliższe mie­sią­ce poka­żą na ile się myli­łem … oba­wiam się, że wie­le spo­rów będzie dało się roz­strzy­gać jedy­nie spro­wa­dza­niem skarg i wnio­sków do absurdu.

__________________
1.
GIODO. GIODO. https://​gio​do​.gov​.pl/​p​l​/​5​6​9​/​9​276. Published June 3, 2018. Accessed June 3, 2018.
2.
Wiedza o RODO rekor­do­wo pil­nie poszu­ki­wa­na – Aktualności / Oddział Mazowiecki PTI. Oddział Mazowiecki PTI. http://​mazow​sze​.pti​.org​.pl/​1​3​,​a​k​t​u​a​l​n​o​s​c​i​/​a​r​t​i​c​l​e​:​273. Published June 3, 2018. Accessed June 3, 2018.
3.
Dziedzinowe mode­le poję­cio­we i struk­tu­ral­ne są pod­sta­wą ana­li­zy sys­te­mo­wej orga­ni­za­cji, pań­stwa, pra­wa itp. Każda ana­li­zę zaczy­nam od opra­co­wa­nia mode­lu bada­nej dziedziny.
4.
Myślenie życze­nio­we (ang. wish­ful thin­king) ? spo­sób rozu­mo­wa­nia i podej­mo­wa­nia decy­zji opie­ra­ją­cy się na wizji ?opty­mi­stycz­ne­go sce­na­riu­sza? w miej­sce odwo­ły­wa­nia się do dowo­dów i racjonalności.

Dokumenty czy niedokumenty.… czyli zarządzanie informacją i jej standaryzacja

Nie raz tu już pisa­łem, że ana­li­zy i pro­jek­ty zwią­za­ne bez­po­śred­nio z wyma­ga­nia­mi na opro­gra­mo­wa­nie to tyl­ko” ok. 3/4 moich pro­jek­tów. Jednak nawet, jeże­li pro­jekt nie jest nazwa­ny” infor­ma­tycz­nym, to zawsze jest infor­ma­cyj­ny” w rozu­mie­niu zarzą­dza­nia infor­ma­cją (tak­że zarzą­dza­nie wie­dzą). Tym razem kil­ka słów na temat doku­men­tów. Stanowią one pod­sta­wo­wą jed­nost­kę infor­ma­cji (i danych) w każ­dym sys­te­mie biz­ne­so­wym. Są tak­że źró­dłem danych dla hur­tow­ni danych.

Wstęp

Wiele pro­jek­tów zwią­za­nych z doku­men­ta­mi jest spro­wa­dza­nych do problemu:

jakie mamy doku­men­ty i co z nimi robimy?”

Zaniedbuje się bar­dzo waż­ny ele­ment: odpo­wiedź na pytanie:

czy nasze obec­ne doku­men­ty, ich ilość i treść, są właściwe?”

Otóż prak­ty­ka poka­zu­je, że dość czę­sto pro­ble­mem są doku­men­ty opra­co­wa­ne kie­dyś tam”. Inicjuje się pro­jekt z róż­ny­mi wyma­ga­nia­mi ale niko­mu nie przy­cho­dzi do gło­wy by zasta­no­wić się nad tym czy obec­ne doku­men­ty, w ich obec­nej posta­ci, są dobrym pomy­słem i powin­ny takie pozostać.

Czy doku­men­ty są nie­zmie­nial­nym bytem? Nie, nie są.

Każda orga­ni­za­cja obra­ca skoń­czo­ną licz­bą doku­men­tów, są to róż­ne­go rodza­ju for­mu­la­rze, w naj­ogól­niej­szym przy­pad­ku doku­men­tem jest po pro­stu każ­da treść, tak­że zwy­kła pro­za” np. notat­ka. Warto jed­nak zwró­cić uwa­gę na to, że nawet ona ma pew­ną struk­tu­rę: np. auto­ra, adre­sa­ta, temat, datę i treść. Dokumenty to okre­ślo­na kon­kret­na treść utrwa­lo­na z okre­ślo­ne­go powo­du (w prze­ciw­nym wypad­ku doku­ment nie by powstał). Osiem lat temu opi­sy­wa­łem kwe­stie róż­ni­cy mię­dzy doku­men­tem, wie­dzą, infor­ma­cją a danymi:

Czy baza danych to wie­dza?[?] Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta infor­ma­cja?. (Źródło: Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting)

Dzisiaj co nie­co o tym, dla­cze­go od cza­su do cza­su war­to się pochy­lić nad wzo­ra­mi doku­men­tów i czy cza­sem nie zmie­nić nie­co podej­ścia do nich.

Dokumenty w organizacji

Swego cza­su u jed­ne­go z moich klien­tów odkry­łem” cie­ka­wy doku­ment. Była to fak­tu­ra z doda­nym zesta­wem danych odpo­wia­da­ją­cym doku­men­tom WZ oraz ana­lo­gicz­nym zesta­wie­niem doty­czą­cym opa­ko­wań zwrot­nych. Ten super doku­ment był pomy­słem z przed wie­lu lat oso­by odpo­wie­dzial­nej za wyda­wa­nie i zarzą­dza­nie opa­ko­wa­nia­mi zwrot­ny­mi w maga­zy­nie. Uzasadnienie brzmia­ło: na jed­nym doku­men­cie będą wszyst­kie infor­ma­cje zwią­za­ne z kon­kret­ną sprze­da­żą i dosta­wą. Brzmi ład­nie jed­nak: prak­tycz­nie każ­dy kto miał z tym doku­men­tem do czy­nie­nia, w toku obsłu­gi zamó­wie­nia, dosta­wał nad­mia­ro­we dane, nie raz nie­jaw­ne (nie­któ­re) ceny, szcze­gó­ły zawar­to­ści paczek, war­tość towa­ru (po co ta wie­dza kie­row­com), ilo­ści i sal­da (tak) opa­ko­wań zwrot­nych (jak się oka­za­ło doku­ment nie raz poma­gał w nad­uży­ciach, nie­któ­rzy pra­cow­ni­cy zaś zama­zy­wa­li cza­sa­mi część danych prze­ka­zu­jąc doku­ment dalej, by ich nie ujaw­niać). Ale naj­więk­szym pro­ble­mem było to, że ta oso­ba uczy­ni­ła z tego wzo­ru doku­men­tu wyma­ga­nie wobec opro­gra­mo­wa­nia ERP. Jak się nie trud­no domy­śleć, żaden ryn­ko­wy sys­tem nie ma takie­go doku­men­tu stan­dar­do­wo, dostaw­ca ERP uznał to wyma­ga­nie bez zastrze­żeń, co przy­czy­ni­ło się do wie­lu mody­fi­ka­cji opro­gra­mo­wa­nia tak­że w innych miej­scach, znacz­ne­go wzro­stu budże­tu (współ­dzie­lo­na baza danych pro­pa­gu­je zmia­ny prak­tycz­nie na całą apli­ka­cję). Nie będę tu opi­sy­wał dal­szych losów tego wzo­ru doku­men­tu bo celem moim było jedy­nie poka­za­nie pro­ble­mu na real­nym przykładzie.

Każdy pro­jekt, czy to wdro­że­nie nowych zasad zarzą­dza­nia czy nowe­go opro­gra­mo­wa­nia, zwią­za­ny z zarzą­dza­niem orga­ni­za­cją, to (powi­nien być) tak­że co naj­mniej prze­gląd doku­men­tów i ich obie­gu. Kluczowym ele­men­tem tego prze­glą­du powin­na być ana­li­za tre­ści tych doku­men­tów, ich opty­mal­ność, nie tyl­ko obie­gu ale tak­że tre­ści i jej struk­tu­ry. Owszem, wie­le doku­men­tów ma narzu­co­ną struk­tu­rę np. w odpo­wied­niej usta­wie, jed­nak są to mini­mal­ne zawar­to­ści (np. fak­tu­ra) nie ma zaka­zu uzu­peł­nie­nia tej struk­tu­ry i np. doda­nia do fak­tu­ry nume­ru zamó­wie­nia, z któ­rym jest związana.

Ogólnie moż­na okre­ślić pew­ne pra­wi­dło­wo­ści: jeże­li doku­men­ty są prze­cią­ża­ne tre­ścią, czy­li idzie­my w kie­run­ku małej ilo­ści doku­men­tów zawie­ra­ją­cych dużo danych, rośnie zło­żo­ność reguł pra­cy z takim doku­men­tem. Jeżeli zaś idzie­my w kie­run­ku doku­men­tów bar­dzo pro­stych”, rośnie ilość ich typów i rośnie licz­ba reguł koja­rzą­cych te doku­men­ty ze sobą w celu ich uży­cia. Ogólnie obra­zu­je to poniż­szy diagram:

Liczba dokumentów vs ilośc treści na nich

Tak więc skraj­nym roz­wią­za­niem będzie stwo­rze­nie jed­ne­go doku­men­tu, na któ­rym będą wszyst­kie infor­ma­cje np. zwią­za­ne z danym zamó­wie­niem. Drugą skraj­no­ścią jest podzie­le­nie infor­ma­cji na odręb­ne małe nie­po­dziel­ne już grup­ki, jak to ma miej­sce w znor­ma­li­zo­wa­nych rela­cyj­nych bazach danych. Jeżeli mega­do­ku­men­ty to raczej bar­dzo rzad­kie zja­wi­sko, to przy­pa­dek dru­gi jest dość powszech­ny. To co nazy­wa­my czę­sto doku­men­tem to tu tak na praw­dę nie­ist­nie­ją­cy byt w rela­cyj­nej bazie danych, gene­ro­wa­ny ad-hoc w locie” z sze­re­gu roz­drob­nio­nych tablic danych. Innymi sło­wy nie są to sta­łe struk­tu­ry” a pew­na okre­ślo­na zło­żo­na logi­ka, two­rzą­ca z pro­stych danych pobie­ra­nych z tablic, kon­kret­ne zesta­wy infor­ma­cji np. fak­tu­ry (to dla­te­go czę­sto w języ­ku dostaw­cy” fak­tu­ra to raport a nie doku­ment!). Ta zło­żo­na logi­ka reali­zo­wa­na jest (wyko­ny­wa­na w pamię­ci kom­pu­te­ra) za każ­dym razem gdy odwo­ła­my się do takie­go dokumentu.

Optymalna sytu­acja to rodzaj kom­pro­mi­su pomię­dzy zło­żo­no­ścią logi­ki two­rze­nia i korzy­sta­nia z doku­men­tu a jego zawar­to­ścią. Na powyż­szym dia­gra­mie jest to obszar sta­no­wią­cy oko­li­ce mini­mum krzy­wej opi­su­ją­cej zależ­ność pomię­dzy licz­bą doku­men­tów a zło­żo­no­ścią ope­ro­wa­nia nimi. Nie ma pro­stej regu­ły na opra­co­wy­wa­nie i opty­ma­li­za­cje tre­ści i licz­by doku­men­tów jed­nak są pew­ne spraw­dzo­ne dobre prak­ty­ki, a mia­no­wi­cie jeden doku­ment, o okre­ślo­nej struk­tu­rze, powi­nien zawie­rać dane o okre­ślo­nym zda­rze­niu w okre­ślo­nym kon­tek­ście [powsta­je teraz publi­ka­cja na ten temat, wyda­je się moż­na to jed­nak zde­fi­nio­wać, przyp auto­ra 2019]. Dokumenty te, podob­nie jak fak­ty któ­re doku­men­tu­ją, mogą mieć każ­dy wła­sny i róż­ny od innych cykl życia, dla­te­go czę­sto bywa bar­dzo szko­dli­we roz­dzie­la­nie” ich na pola bazy danych i pozby­cie się redundancji.

Przykładem mogą być: zamó­wie­nie jako udo­ku­men­to­wa­nie fak­tu zawar­cia umo­wy na dosta­wę, fak­tu­ra jako udo­ku­men­to­wa­nie fak­tu sprze­da­ży (prze­nie­sie­nia wła­sno­ści) oraz doku­ment WZ doku­men­tu­ją­cy fakt wyda­nia z maga­zy­nu okre­ślo­nych pro­duk­tów. Bardzo czę­sto spe­cy­fi­ka­cja tego co wyda­no z maga­zy­nu nie jest toż­sa­ma z tre­ścią fak­tu­ry (sprze­da­no odku­rzacz a wyda­no odku­rzacz i zapa­so­we wor­ki), na zamó­wie­niu mógł być wyszcze­gól­nio­ny odku­rzacz, wor­ki oraz wyma­ga­ne koń­ców­ki (któ­re są np. u pro­du­cen­ta pako­wa­ne w stan­dar­dzie więc nie ma ich ani na fak­tu­rze ani na WZ). Dlatego ma głę­bo­ki sens by te doku­men­ty były jed­nak osob­ny­mi doku­men­ta­mi” a nie zacho­wy­wa­ny­mi w bazie danych dany­mi jako odręb­ne pola pozba­wio­ne redun­dan­cji, wyma­ga­ją­ce skom­pli­ko­wa­nej logi­ki (pole­ce­nia SQL) by je (te doku­men­ty”) poka­zać na ekra­nie czy wydrukować.

To dość try­wial­ny przy­kład, bo opi­sa­ne doku­men­ty są wyma­ga­ne prze­pi­sa­mi jako dowo­dy księ­go­we, jed­nak każ­da więk­sza orga­ni­za­cja ma swo­je wewnętrz­ne doku­men­ty, na któ­rych ilość i treść ma peł­ny wpływ. Po dru­gie nawet te doku­men­ty są czę­sto wła­śnie zapi­sy­wa­ne w rela­cyj­nych bazach danych jako roz­pro­szo­ne po małych tabe­lach dane, wyma­ga­ją­ce skom­pli­ko­wa­nych ope­ra­cji łącze­nia w jeden doku­ment”, każ­do­ra­zo­wo przy pró­bie jego uży­cia. Tu zacho­dzi bar­dzo duże ryzy­ko, że postać i treść takie­go doku­men­tu ule­gnie zmia­nie np. po reor­ga­ni­za­cji bazy danych. Takich doku­men­tów” nie da się (w tej posta­ci) pod­pi­sać elek­tro­nicz­nie, bo one po pro­tu fizycz­nie na praw­dę nie istnieją.

A jak ina­czej? Nie ma żad­ne­go pro­ble­mu by dowol­ny doku­ment sta­no­wił sobą jed­no­li­ty byt np. zestaw danych w for­ma­cie XML, sko­ja­rzo­ny ewen­tu­al­nie ze swo­ją posta­cią goto­wą do dru­ku albo np. plik PDF sko­ja­rzo­ny z meta­da­ny­mi opi­su­ją­cy­mi go (wybór jest na praw­dę duży). Nie nale­ży zapo­mi­nać, że poza doku­men­ta­mi, któ­re są two­rzo­ne w orga­ni­za­cji ope­ru­je­my doku­men­ta­mi obcy­mi, otrzy­ma­ny­mi z zewnątrz i wypa­da­ło by mieć taki doku­ment w posta­ci takiej jaką prze­słał nam ich twór­ca. Owszem poja­wia się redun­dan­cja danych ale ona nie sta­no­wi sobą nic złe­go. Ogromną korzy­ścią takie­go podej­ścia jest roz­wią­za­nie pro­ble­mu pole­ga­ją­ce­go na nie­moż­no­ści roz­dzie­le­nia doku­men­tów” i logi­ki ope­ro­wa­nia nimi jeże­li są zapi­sa­ne w posta­ci odręb­nych pól w rela­cyj­nej bazie danych. Np. sta­je się nie­moż­li­we pozo­sta­wie­nie fak­tur i wynie­sie­nie doku­men­tów maga­zy­no­wych do odręb­ne­go sys­te­mu (w tym zmia­na ich struk­tu­ry) co ma miej­sce nie raz przy wdra­ża­niu sys­te­mów WMS (sys­te­my logi­stycz­no-maga­zy­no­we). Takie ope­ra­cji pra­wie żaden duży zin­te­gro­wa­ny ERP nie wytrzy­ma (usły­szy­my raczej, że my dosto­su­je­my do Państwa potrzeb nas moduł magazynowy…).

Podejście takie ma tak­że inna cie­ka­wą zale­tę: jeże­li udo­ku­men­tu­je­my osob­no struk­tu­ry doku­men­tów i logi­kę ope­ro­wa­nia nimi (tak­że ich two­rze­nia), to otrzy­ma­my obiek­to­wy model orga­ni­za­cji: model poka­zu­ją­cy wza­jem­ną współ­pra­cę obiek­tów biz­ne­so­wych (doku­men­tów) odpo­wie­dzial­nych za prze­cho­wy­wa­nie infor­ma­cji, obiek­tów odpo­wie­dzial­nych za reje­stro­wa­nie tych infor­ma­cji, obiek­tów mają­cych wie­dzę jak ope­ro­wać tymi infor­ma­cja­mi, obiek­tów udo­stęp­nia­ją­cych to wszyst­ko zgod­nie z okre­ślo­ną logi­ką. Poniżej obiek­to­wy model na któ­rym od pra­wej mamy: doku­men­ty z ich tre­ścią oraz logi­kę ich two­rze­nia i udo­stęp­nia­nia (repo­zy­to­ria czy­li kuwet­ki na doku­men­ty), logi­kę korzy­sta­nia z infor­ma­cji w repo­zy­to­riach, tak­że ich wza­jem­ne­go koja­rze­nia (samo­dziel­ne usłu­gi) oraz logi­kę dostę­pu do tego sys­te­mu (reali­za­cja sce­na­riu­szy przy­pad­ków uży­cia). Jeżeli w toku ana­li­zy uzna­my, że jakieś ele­men­ty tej logi­ki to zada­nia pod­da­ją­ce się w 100% algo­ryt­mi­za­cji, to poniż­szy model jest jed­no­cze­śnie mode­lem logi­ki apli­ka­cji i nazy­wa­my go Modelem Dziedziny Systemu. Nie jest to abso­lut­nie żad­na baza danych, poniż­sze repo­zy­to­ria nicze­go nie współ­dzie­lą (moż­na je w dowol­nym momen­cie zamie­niać na inne bez kon­se­kwen­cji dla resz­ty systemu).

Obiektowy model dziedziny Zasada SOLID

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. (Źródło: Krzywe i kosz­ty? archi­tek­tu­ry | | Jarosław Żeliński IT-Consulting

Prawie zawsze obser­wu­ję, że pod­sta­wo­wym domyśl­nym zało­że­niem wdro­żeń sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie, jest uzna­nie a prio­ri nie­zmien­no­ści struk­tu­ry i wzo­rów dokumentów. 

Z doświad­cze­nia mogę powie­dzieć, że ana­li­za i opty­ma­li­za­cja tre­ści doku­men­tów wewnętrz­nych może przy­nieść bar­dzo duże korzy­ści prze­kła­da­ją­ce się na duży wzrost wewnętrz­nej efek­tyw­no­ści i jako­ści pra­cy, a w przy­pad­ku wdro­żeń opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, pozwa­la nie raz cał­ko­wi­cie unik­nąć bar­dzo kosz­tow­nych i ryzy­kow­nych kasto­mi­za­cji. Zaryzykuje tezę, że kil­ka pro­jek­tów w ten spo­sób wręcz uratowałem… 

Model pojęciowy, model danych, model dziedziny systemu

Niemalże każ­de spo­tka­nie pro­jek­to­we, na któ­rym oma­wia­ne są mode­le UML, na każ­dym szko­le­niu na temat UML, poja­wia się pro­blem o któ­rym pisze Ron Ross (wytłusz­cze­nia moje):

Another impli­ca­tion is that con­cept models and logi­cal data models are cle­ar­ly distinct. Unfortunately, many people blur the line betwe­en them. That?s wrong. A con­cept model is abo­ut the meaning of the words you use, and the busi­ness sta­te­ments you make assu­ming tho­se meanings. It?s abo­ut com­mu­ni­ca­tion. A logi­cal data model is abo­ut how you orga­ni­ze what you think you know abo­ut the world so it can be recor­ded and logi­cal­ly mani­pu­la­ted in a sys­te­ma­tic way.I star­ted my care­er in data. It took me as much as 15 years of inten­se work on busi­ness rule sta­te­ments (1990 – 2005) to ful­ly appre­cia­te the dif­fe­ren­ce. But now I am very cle­ar that con­cept models do need to be deve­lo­ped to excru­cia­ting level of deta­il in order to disam­bi­gu­ate the inten­ded busi­ness communication.Most busi­nesses don?t do that today. They jump in at data design (con­cep­tu­al, logi­cal or even phy­si­cal). And they unk­no­win­gly pay a big pri­ce for it. (Źródło: Concept Model vs. Data Model ? Ron Ross on Business Rules)

Generalnie model poję­cio­wy, model danych to skraj­nie róż­ne mode­le. Jeżeli do tego doda­my dys­ku­sje na temat obiek­to­we­go mode­lu dzie­dzi­ny, to na spo­tka­niu mamy nie­mal­że gwa­ran­cje ostre­go sporu.

Widzę dwa głów­ne źró­dła tych pro­ble­mów. Pierwsze to fakt, że w szko­łach wyż­szych nadal kró­lu­je ana­li­za struk­tu­ral­na, a po maco­sze­mu trak­to­wa­na ana­li­za sys­te­mo­wa i obiek­to­wa (obie bazu­ją na kon­cep­cji współ­pra­cu­ją­cych obiek­tów i ope­ru­ją poję­ciem obiekt zaś ter­min” to poję­cie słow­ni­ko­we). Teoria sys­te­mów i opar­ty na niej para­dyg­mat obiek­to­wy są nie­ste­ty trud­ne, bazu­ją w 100% na her­me­ty­za­cji i abs­tra­ho­wa­niu od szcze­gó­łów, a ode­rwa­nie się od szcze­gó­łów więk­szo­ści ludziom przy­cho­dzi z ogrom­nym tru­dem albo nie uda­je się w ogó­le. Drugie to powszech­ne myle­nie kon­tek­stów słów ter­min” (poję­cie) i kon­cep­cja” (pomysł, idea) w lite­ra­tu­rze anglojęzycznej:

con­cept {rzecz.} (też: notion, idea, con­cep­tion, term) poję­cie {n.} Same con­cept, but looking at com­mu­ni­ca­tion dyna­mics in a very dif­fe­rent sphe­re. To samo poję­cie, ale patrząc na dyna­mi­kę komu­ni­ka­cji w zupeł­nie odmien­nej sferze.

con­cept {rzecz.} (też: con­cep­tion, idea) kon­cep­cja {f.} However, we ought to be awa­re that the con­cept of vic­ti­mi­sa­tion requ­ires strong pro­of. Musimy jed­nak być świa­do­mi, że kon­cep­cja repre­sjo­no­wa­nia wyma­ga moc­nych dowodów.

term {rzecz.} (też: notion, idea, con­cep­tion, con­cept) poję­cie {n.} Really cool term: neo­te­ny – the reten­tion of play and juve­ni­le tra­its in adults. Świetne poję­cie – neo­te­nia, zacho­wa­nie u doro­słych mło­dzień­czych cech i chę­ci do zabawy.

(źr. http://​pl​.bab​.la/​s​l​o​w​n​i​k​/​a​n​g​i​e​l​s​k​i​-​p​o​l​s​k​i​/​c​o​n​c​ept)

Do tego docho­dzą nota­cje i cza­sa­mi wręcz nie zro­zu­mie­nie ich seman­ty­ki i zasto­so­wa­nia. W oma­wia­nym obsza­rze od lat są sto­so­wa­ne dwie, od nie­daw­na trzy notacje:

  1. dia­gram związ­ków encji (naj­po­pu­lar­niej­sze nota­cje to Crow?s Feet” czy­li kurze stop­ki 🙂 i jej wer­sja zwa­na, nota­cją bar­ke­ra (Barker’s nota­tion, ERD, ang. Entity Relationship Diagram)
  2. dia­gram klas nota­cji UML (ang. Unified Modeling Language)
  3. dia­gram fak­tów (ang. SBVR, Semantics Of Business Vocabulary And Rules)

Pierwszy słu­ży do two­rze­nia mode­li w para­dyg­ma­cie rela­cyj­nym na trzech pozio­mach ogól­no­ści, wszyst­kie trzy są mode­la­mi danych (a nie pojęć):

  1. Conceptual data model
  2. Logical data model
  3. Physical data model

Diagram klas w nota­cji UML słu­ży do two­rze­nia modeli:

  1. poję­cio­wych (wszyst­kie dia­gra­my klas w spe­cy­fi­ka­cjach OMG to mode­le poję­cio­we opi­su­ją­ce seman­ty­ką i syn­tak­ty­kę danej notacji),
  2. mode­li obiek­to­wych (dia­gram obiek­tów) i ich meta­mo­de­li (dia­gram klas), są to tak zwa­ne mode­le dzie­dzi­ny sys­te­mu (logi­ka, mecha­nizm dzia­ła­nia apli­ka­cji, przed­się­bior­stwa, każ­de­go sys­te­mu w rozu­mie­niu teo­rii systemów),
  3. mode­li struk­tu­ry kodu apli­ka­cji (dia­gram klas).

Od nie­daw­na mamy nota­cje SBVR a w niej dia­gram Fact dia­gram”. Jest to dia­gram (nie jest to dia­gram klas UML, ale dia­gra­mu klas UML moż­na użyć by go zastą­pić) repre­zen­tu­ją­cy w for­mie gra­ficz­nej słow­nik pojęć i jest to spe­cy­ficz­ny model poję­cio­wy, opar­ty na tak zwa­nych związ­kach opar­tych na fak­tach (aso­cja­cje repre­zen­tu­ją tu fak­ty, któ­re kon­tek­sto­wo koja­rzą dane dwa poję­cia np. doku­ment opi­su­je zda­rze­nie, pod­kre­śle­nia wska­zu­ją na poję­cia ze słow­ni­ka (są w nim zde­fi­nio­wa­ne) o sło­wo pisa­ne kur­sy­wą to fakt, któ­ry je kon­tek­sto­wo koja­rzy (mode­le fak­tów to nie są ontologie).

Modele danych (np. dia­gra­my ERD) to struk­tu­ry poka­zu­ją­ce orga­ni­za­cję danych (infor­ma­cji). Mogą być na dużym pozio­mie abs­trak­cji w posta­ci wstęp­ne­go pomy­słu”, mogą być wypra­co­wa­nym mode­lem i mogą być mniej lub bar­dziej kom­pro­mi­so­wym pla­nem implementacji.

Obiektowy para­dyg­mat oraz ogól­na teo­ria sys­te­mów zakła­da­ją, że wszyst­ko to co obser­wu­je­my to pew­na więk­sza lub mniej­sza zło­żo­ność opi­sa­na jako skoń­czo­na licz­ba współ­pra­cu­ją­cych ele­men­tów (lub ich klas). Każdy ele­ment ma okre­ślo­ne cechy, każ­dy w okre­ślo­ny spo­sób reagu­je na bodź­ce z oto­cze­nia. Całkowitą zło­żo­ność wyzna­cza licz­ba tych ele­men­tów i pro­sto­ta lub jej brak, reak­cji na bodź­ce. Doskonale tłu­ma­czy to meta­fo­ra K.Poppera o zega­rach i chmurach:

Generalnie pro­blem zło­żo­no­ści ład­nie opi­sał Karl Popper, w swo­im dzie­le Wiedza Obiektywna meta­fo­rą ?o chmu­rach i zega­rach?. To co obser­wu­je­my, sys­tem, może być tak zło­żo­ne, że ilość obiek­tów i ich wza­jem­nych oddzia­ły­wań będzie zbyt duża, by moż­li­we było stwo­rze­nie mode­lu (teo­ria wyja­śnia­ją­ca zacho­wa­nie) takie­go sys­te­mu, pozwa­la­ją­ce­go na prze­wi­dy­wa­nie zacho­wa­nia takiej zło­żo­no­ści. Są jed­nak sys­te­my, któ­rych natu­ra na to pozwa­la, ich model jest moż­li­wy do stwo­rze­nia, takie sys­te­my są prze­wi­dy­wal­ne w 100%. Metaforą sys­te­mu nie­prze­wi­dy­wal­ne­go jest chmu­ra, a prze­wi­dy­wal­ne­go zegar. Oczywiście jest nie­skoń­cze­nie wie­le sys­te­mów o natu­rze gdzieś pomię­dzy chmu­ra­mi i zega­ra­mi. (Źródło: Wszystkie dro­gi pro­wa­dzą do Rzymu | | Jarosław Żeliński IT-Consulting)

Elementy sys­te­mu mają swo­je cechy (ukry­te: her­me­ty­za­cja) a uze­wnętrz­nia­ją wyłącz­nie reak­cje na bodź­ce (żąda­nia). W efek­cie sys­tem żyje” ale nie jest bazą danych”. UML i dia­gram klas, w tym wypad­ku, mode­lu­je współ­pra­cu­ją­ce obiek­ty a nie bazę danych”. To, że taka baza (każ­da for­ma utrwa­la­nia danych) fizycz­nie ist­nie­je (jest two­rzo­na) to wyłącz­nie sku­tek potrze­by jaką jest zapa­mię­ta­nie sta­nu sys­te­mu (apli­ka­cji).

Niewątpliwie jed­nak dia­gram klas UML nie jest mode­lem danych, i nie słu­ży do mode­lo­wa­nia danych… 

Model kom­po­nen­tu sys­te­mu, opi­su­ją­cy mecha­nizm jego dzia­ła­nia (logi­kę) to tak zwa­ny model dzie­dzi­ny” czy­li obiek­to­wy model sys­te­mu opi­su­ją­cy (mode­lu­ją­cy) mecha­nizm jego dzia­ła­nia. Owszem, apli­ka­cja może słu­żyć do zarzą­dza­nia duży­mi i zor­ga­ni­zo­wa­ny­mi zbio­ra­mi danych ale to to samo co zespół ludzi – sys­tem współ­pra­cu­ją­cych obiek­tów mają­cych – każ­dy – wie­le cech – zarzą­dza­ją­cy biblio­te­ką: Ci ludzie i ich cechy to nie baza danych” a ukry­te do ich wia­do­mo­ści cechy i umie­jęt­no­ści, dostęp­ne dla innych wyłącz­nie pod warun­kiem zada­nia pyta­nia i woli odpo­wie­dzi na nie, ci ludzie mogą zarzą­dzać” jakimś zbio­rem danych. 

Dlatego ubo­le­wam, gdy oso­by będą­ce nauczy­cie­la­mi aka­de­mic­ki­mi, tre­ne­ra­mi pro­wa­dzą­cy­mi szko­le­nia czy auto­ra­mi wie­lu uczo­nych” blo­gów, publi­ku­ją pomy­sły o mode­lo­wa­niu danych z uży­ciem UML… co nie ma nic wspól­ne­go z UML.

O SBVR, mode­lach poję­cio­wych i dia­gra­mie fak­tów pisa­łem w arty­ku­le SBVR czy­li regu­ły biz­ne­so­we i słow­nik. Kwestie dia­gra­mów klas opi­sa­łem mię­dzy inny­mi w arty­ku­le Cholerny dia­gram klas i w Czym jest a czym nie jest model dzie­dzi­ny. Jeśli zaś cho­dzi o to czym nie jest dia­gram ERD pisa­łem przy oka­zji Wiedza po stu­diach? Zostaliście oszukani?

TDD – czy same testy to wymagania?

Na nie­daw­no zakoń­czo­nej kon­fe­ren­cji beIT orga­ni­zo­wa­nej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygło­si­łem refe­rat zaty­tu­ło­wa­ny Filozofia czy­li Aplikacja jako ele­ment biz­ne­so­wej rze­czy­wi­sto­ści (a nie gra kom­pu­te­ro­wa). Przesłanie tej pre­zen­ta­cji to:

Oprogramowanie bar­dzo czę­sto zastę­pu­je kon­struk­cje rze­czy­wi­ste takie jak zega­rek, kar­to­te­ka, biblio­te­ka, księ­gi han­dlo­we, pro­gra­ma­tor pral­ki i wie­le innych rze­czy. Dlatego ana­li­za powin­na pole­gać na zro­zu­mie­niu i udo­ku­men­to­wa­niu mecha­ni­zmu dzia­ła­nia tego cze­goś” a nie jedy­nie na spi­sa­niu zewnętrz­nych oznak tego dzia­ła­nia i zarzą­dza­nie tym spisem. 

Referat miał lek­kie pod­ło­że filozoficzne :).

Ten arty­kuł nie będzie jed­nak powtó­rze­niem refe­ra­tu (wyżej link do pobra­nia). Do jego napi­sa­nia skło­ni­ło mnie jed­no z pytań z sali:

Stosujemy TDD, czy to nie wystar­czy? Po co więc robić to o czym Pan mówi?”

Otóż odpo­wiedź brzmia­ła: TDD nie zastę­pu­je opi­su mecha­ni­zmu dzia­ła­nia. Innymi sło­wy: sam zestaw testów bar­dzo czę­sto nie sta­no­wi żad­nej infor­ma­cji o tym co ma powstać.

Niedawno pisa­łem:

Mechanizm jed­nak to nie zawsze tyl­ko same regu­ły, bar­dzo czę­sto (prak­tycz­nie zawsze dla nie­try­wial­nych sys­te­mów) powi­nien powstać dia­gram poka­zu­ją­cy wewnętrz­ną budo­wę (archi­tek­tu­rę) sys­te­mu, zestaw kom­po­nen­tów odpo­wie­dzial­nych za logi­kę reali­zo­wa­nia tych reguł (a jed­ną z nich jest np. ?treść doku­men­tów musi być zapa­mię­ty­wa­na z moż­li­wo­ścią przy­wo­ła­nia jej w dowol­nym momen­cie?). Taki dia­gram nazy­wa się Model dzie­dzi­ny. Jak go two­rzyć pisa­łem nap. w arty­ku­le Model dzie­dzi­ny jako wyma­ga­nie. (Źródło: Model To Mechanizm | | Jarosław Żeliński IT-Consulting)

A teraz jako przy­kład przy­to­czę dość zło­żo­ny kom­po­nent wie­lu sys­te­mów (pogru­bie­nie moje):

Jak dzia­ła sco­ring w Banku. Klient zain­te­re­so­wa­ny uzy­ska­niem kre­dy­tu wypeł­nia wnio­sek kre­dy­to­wy dla wybra­ne­go pro­duk­tu kre­dy­to­we­go. Dane z wnio­sku reje­stro­wa­ne są w sys­te­mie infor­ma­tycz­nym, któ­ry wspo­ma­ga pro­ces obsłu­gi wnio­sków kre­dy­to­wych w Banku. Podczas prze­twa­rza­nia wnio­sku nastę­pu­je wery­fi­ka­cja danych oraz zapy­ta­nie o auto­ma­tycz­ną reko­men­da­cję kre­dy­to­wą kie­ro­wa­ną do sil­ni­ka decy­zyj­ne­go. Silnik decy­zyj­ny wyko­nu­je zde­fi­nio­wa­ny w posta­ci reguł prze­twa­rza­nia algo­rytm sco­rin­go­wy: gro­ma­dzi dodat­ko­we infor­ma­cje z dostęp­nych źró­deł (np. Biuro Informacji Kredytowej SA, bazy nie­so­lid­nych klien­tów oraz dowo­dów zastrze­żo­nych ? MIG BR, MIG DZ), wyzna­cza wskaź­ni­ki, okre­śla przy­dział do klas ryzy­ka oraz wyli­cza oce­nę punk­to­wą w opar­ciu o kar­ty sco­rin­go­we. (Źródło: Scoring – meto­da oce­ny wia­ry­god­no­ści kre­dy­to­wej – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Odpowiadając na pyta­nie o TDD powiem tak: nie da się jed­no­znacz­nie zamó­wić” Systemu sco­rin­go­we­go, poda­jąc jedy­nie par­tię danych wej­ścio­wych i spo­dzie­wa­nych danych wyj­ścio­wych. Testy moż­na opra­co­wać zna­jąc mecha­nizm dzia­ła­nia tego sys­te­mu, two­rzy­my wte­dy repre­zen­ta­tyw­ny zestaw testów pokry­wa­ją­cy cały kod”, o ile zna­my struk­tu­rę tego kodu (pro­jekt). Sam kod nie musi ist­nieć w momen­cie pro­jek­to­wa­nia tych testów, ale opra­co­wa­ny mecha­nizm tak, bo jak już pisa­łem model dzie­dzi­ny to struk­tu­ra kodu reali­zu­ją­ce­go logi­kę biz­ne­so­wą wraz z metodami”.

Można tu powie­dzieć, że nie każ­dy sys­tem to zło­żo­ność sys­te­mu sco­rin­go­we­go. To praw­da, ale to co nazy­wa­my biz­ne­sem to regu­ły biz­ne­so­we, mecha­nizm dzia­ła­nia orga­ni­za­cji, a ten nigdy nie jest try­wial­ny. Reguły udzie­la­nia upu­stów, regu­ły przy­dzie­la­nia kre­dy­tów kupiec­kich, regu­ły nagra­dza­nia w sys­te­mach lojal­no­ścio­wych, regu­ły roz­li­cza­nia kosz­tów i wie­le, wie­le innych w pra­wie każ­dej fir­mie, orga­ni­za­cji czy insty­tu­cji publicznej.

Prawdopodobieństwo tego, że powsta­nie popraw­ne” opro­gra­mo­wa­nie tyl­ko na pod­sta­wie zapi­su sze­re­gu zewnętrz­nych obser­wa­cji” (bo czym są wyma­ga­nia jako zapis burz mózgów, ankiet, wywia­dów, itp.?) jest tym bar­dziej bli­skie zeru im bar­dziej orga­ni­za­cja ma zło­żo­ny mecha­nizm dzia­ła­nia (czy­li większość).

Zjawisko to jest zna­ne już od dzie­siąt­ków lat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Dlatego roz­wią­za­nie nie­try­wial­ne­go pro­ble­mu nie pole­ga na spe­cy­fi­ko­wa­niu tego co zna­my, a na pod­ję­ciu pró­by zapro­jek­to­wa­nia roz­wią­za­nia. Tym pro­jek­tem nie jest jed­nak opis reak­cji syst­se­mu na bodź­ce” (czar­na skrzyn­ka). Projektem jest opi­sa­ny (jed­no­znacz­nie udo­ku­men­to­wa­ny) mecha­nizm dzia­ła­nia roz­wią­za­nia (bia­ła skrzynka).

Dlatego wyma­ga­nia spe­cy­fi­ku­je­my sku­tecz­nie poprzez pro­jekt pro­duk­tu a nie poprzez listę cech pro­duk­tu. Zamówienie dla deve­lo­pe­ra powin­no zawie­rać pro­jekt a nie wizu­ali­za­cję efek­tu koń­co­we­go, dokład­nie tak jak w bran­ży budow­la­nej, elek­tro­nicz­nej czy nawet mecha­nicz­nej (nawet wyko­naw­ca wału kor­bo­we­go dosta­je rysun­ki tech­nicz­ne a nie roz­wle­kłą proś­bę o faj­ny wał do samochodu).

Zilustrować to moż­na tak:

Wymagania

  1. Wymagania biz­ne­so­we zgła­sza biz­nes, są one for­mą opi­su i kon­se­kwen­cją pro­ble­mu biz­ne­so­we­go, wyma­ga­nia wobec roz­wią­za­nia to usta­lo­ny zakres projektu.
  2. Jeżeli jest to pro­jekt z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, ma powstać opro­gra­mo­wa­nie opi­sa­ne z uży­ciem Przypadków uży­cia i Modelu dziedziny.
  3. Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Kto ma opra­co­wać to ostat­nie? Programista? A na jakiej pod­sta­wie, sko­ro nie zna tego biz­ne­su” (to pro­gra­mi­sta a nie ana­li­tyk biz­ne­so­wy)? Czy same przy­pad­ki uży­cia opi­su­ją regu­ły (mecha­nizm dzia­ła­nia) dzia­ła­nia syst­se­mu sco­rin­go­we­go czy sys­te­mu upu­stów w pro­mo­cji (to jed­na licz­ba, war­tość upu­stu, na fak­tu­rze)? Nie. Czy da się na bazie par­tii testów (czy­li skoń­czo­nej, ale z regu­ły nie­zu­peł­nej liście bodziec-odpo­wiedź) stwo­rzyć cokol­wiek? Mało kie­dy. Oznacza to, że wyma­ga­nia zebra­ne tyl­ko jako przy­pad­ki uży­cia mało kie­dy” dają szan­sę na powsta­nie opro­gra­mo­wa­nia za pierw­szym razem”, tu pro­to­ty­pów nie jest nigdy prze­wi­dy­wal­na. To dla­te­go meto­dy zwa­ne zwin­ny­mi, bazu­ją­ce wyłącz­nie na user sto­ry i pro­to­ty­pach, nada­ją się do pro­ble­mów pro­stych. Kompletnie nie spraw­dza­ją się w przy­pad­kach zło­żo­nych sys­te­mów, rozu­mia­nych jako zło­żo­ne mecha­ni­zmy. Te ostat­nie trze­ba nie raz od zera” odkryć i opisać.

Paradygmat i metody obiektowe

Kluczem metod obiek­to­wych (i para­dyg­ma­tu obiek­to­we­go) jest her­me­ty­za­cja. Oznacza to, że zło­żo­ność obiek­tu z zewnątrz” nie jest zna­na nigdy, nie ma zna­cze­nia wiel­kość obiek­tu (mała kla­sa czy mega-kom­po­nent), na zewnątrz postrze­ga­ny jest wyłącz­nie jako inter­fejs. Rozważania na począt­ku poka­za­ły, że odpo­wie­dzi na bodź­ce to ocze­ki­wa­ne (wyma­ga­ne) cechy roz­wią­za­nia, któ­re jed­nak nie deter­mi­nu­ją jego mechanizmu.

Oprogramowanie poma­ga­ją­ce w nauce tablicz­ki mno­że­nia do 100, może zawie­rać sta­tycz­ną tabli­cę zna­ną z ostat­nich stron sta­rych zeszy­tów, a może to być mecha­nizm będą­cy imple­men­ta­cją algo­ryt­mu mno­że­nia. Po pierw­sze zestaw testów, jak widać, nie deter­mi­nu­je żad­nej z tych metod imple­men­ta­cji. Po dru­gie spe­cy­fi­ka­cja w pierw­szym wypad­ku będzie duża” (kosz­tow­na), w dru­gim bar­dzo pro­sta. Po trze­cie roz­wi­ja­nie (tablicz­ka mno­że­nia do 1000) opro­gra­mo­wa­nia w wer­sji z tabli­cą sta­tycz­ną będzie znacz­nie droż­sze niż pier­wot­ne wytwo­rze­nie wer­sji z mno­że­niem do 100. W dru­gim przy­pad­ku będzie pole­ga­ło wyłącz­nie na zdję­ciu blo­ka­dy mno­że­nia liczb więk­szych niż 10.

Tak więc co z tym TDD? Popatrzmy na to jak jest definiowane:

Co to jest Test Driven Development

Test Driven Development, czy­li TDD, to tech­ni­ka two­rze­nia opro­gra­mo­wa­nia ste­ro­wa­na przez testy. Tworzenie kodu skła­da się z wie­lo­krot­nie wyko­ny­wa­nych trzech głów­nych kroków:

  1. Stworzenie testu jed­nost­ko­we­go, któ­ry powi­nien być moż­li­wie naj­prost­szy, aby unik­nąć moż­li­wo­ści popeł­nie­nia błę­du w samym teście. Test ma spraw­dzać funk­cjo­nal­ność, któ­ra będzie imple­men­to­wa­na w kro­ku 2.
  2. Implementacja funk­cjo­nal­no­ści ? two­rzy­my funk­cjo­nal­ność, któ­rą chce­my zaim­ple­men­to­wać. Funkcjonalność ta powin­na speł­niać zało­że­nia testu jed­nost­ko­we­go, a wyko­na­nie testu jed­nost­ko­we­go powin­no koń­czyć się sukcesem.
  3. Refaktoryzacja, czy­li porząd­ki w stwo­rzo­nej funk­cjo­nal­no­ści. Ma to na celu upo­rząd­ko­wa­nie kodu, tak aby speł­nio­ne były stan­dar­dy. Czynności wyko­ny­wa­ne w tym kro­ku nie mogą zmie­nić wyni­ku testów.

Źródło: Test Driven Development

Pod poję­ciem funk­cjo­nal­ność tu rozu­mia­ny jest ocze­ki­wa­ny efekt”, bo test nie jest niczym innym. Czy testy to są (zastę­pu­ją) pro­jekt wewnętrz­nej logi­ki? W przy­pad­kach try­wial­nych pew­nie tak, tam gdzie logi­ka jest pro­sta lub nie wystę­pu­je (przy­pad­ki uży­cia typu CRUD), albo tam gdzie logi­ka” jest powszech­nie zna­na” zna ją tak­że pro­gra­mi­sta (np. spo­sób dzia­ła­nia zegara).

Jednak sys­tem o nie­try­wial­nej logi­ce dzia­ła­nia, nie da się wyspe­cy­fi­ko­wać w posta­ci skoń­czo­nej (lub roz­sąd­nie krót­kiej) listy bodziec-efekt (np. przy­kła­do­wych par­tii gry w sza­chy). W jed­nej ze swo­ich ksią­żek Martin Fowler napi­sał, że żad­na ilość godzin fil­mu znad sto­łu bilar­do­we­go, jako wyma­ga­nie, nie da w efek­cie nawet namiast­ki dobrej gry w bilar­da. Ale sche­mat sto­łu, wymia­ry kul, kija oraz pra­wa fizy­ki rzą­dzą­ce ruchem kul, pozwo­lą na napi­sa­nie wręcz dosko­na­łej symu­la­cyj­nej gry. Taki opis to wła­śnie model dzie­dzi­ny gry w sza­chy, dokład­ny opis mecha­ni­zmu tego co dzie­je się na sto­le bilardowym.

Ostatnie pyta­nie brzmia­ło: Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Odpowiedź na to pyta­nie zawie­ra pewien arty­kuł, napi­sa­ny w 2014 roku na nie­co inny temat:

…rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych par­tii. (Źródło: Warsztaty Analityczne ? Czyli Malowanie Trawy | | Jarosław Żeliński IT-Consulting)

Tak więc robi­my to tak, jak w innych dzie­dzi­nach inży­nie­rii: ana­li­zu­je­my, pro­jek­tu­je­my i zle­ca­my wyko­na­nie (imple­men­ta­cję).

Na zakończenie

Kim jest, człon­kiem któ­re­go zespo­łu jest (powi­nien być) pro­jek­tant? Przewrotnie odpo­wiem, że prak­ty­ka poka­zu­je, że – z powo­du ryzy­ka pro­jek­to­we­go – wyko­naw­ca nie powi­nien sam sobie sta­wiać wyma­gań. To dla­te­go zło­żo­ne i ryzy­kow­ne pro­jek­ty mają wydzie­lo­ną rolę ana­li­ty­ka pro­jek­tan­ta, nie jest to czło­nek zespo­łu biz­ne­su ani deve­lo­pe­ra bo obie te stro­ny mają sprzecz­ne inte­re­sy (zakres i koszt). W bran­ży budow­la­nej jest to Biuro Projektowe (tu archi­tekt), trze­ci nie­za­leż­na rola, poza inwe­sto­rem i wyko­naw­cą (z uwa­gi na ryzy­ko, pra­wo budow­la­ne zabra­nia łącze­nia jakiej­kol­wiek z tych trzech ról). W meto­dy­kach takich jak SCRUM, jest to Product Owner, i z powyż­sze­go powo­du nie jest dobrze gdy jest to czło­wiek developera”.

Wymiarowanie oprogramowania

Bardzo czę­sto spo­ty­kam się z meto­da­mi wymia­ro­wa­nia opro­gra­mo­wa­nia, czy­li mówiąc ludz­kim języ­kiem: oce­ny pra­co­chłon­no­ści jego wytwo­rze­nia. Typowym argu­men­tem za sto­so­wa­niem tych metod jest potrze­ba pla­no­wa­nia. Nie raz spo­ty­kam się z porów­na­nia­mi do pomia­ru powierzch­ni np. w budow­nic­twie (cytat celo­wo ze stro­ny sto­sow­ne­go stowarzyszenia):

Wymiarowanie opro­gra­mo­wa­nia, ma podob­ne zna­cze­nie, co wymia­ro­wa­nie w innych dzie­dzi­nach inży­nie­rii. Określa wiel­kość, pozwa­la na porów­ny­wa­nie róż­nych przed­się­wzięć, sza­co­wa­nie kosz­tów wytwa­rza­nia i lep­sze pla­no­wa­nie. Punkty funk­cyj­ne ? naj­bar­dziej popu­lar­na i pro­mo­wa­na przez spe­cja­li­stów jed­nost­ka wiel­ko­ści opro­gra­mo­wa­nia, to przy­kła­do­wo odpo­wied­nik metrów kwa­dra­to­wych w budow­nic­twie. Wyobraźmy sobie tę bran­żę, przy zało­że­niu, że nie posłu­gu­je­my się żad­ną jed­nost­ką powierzch­ni. Inwestycje były­by wyce­nia­ne, a ich reali­za­cja pla­no­wa­na nawet bez pró­by osza­co­wa­nia np. powierzch­ni użyt­ko­wej? Wydaje się to absur­dem, a jed­nak w takiej rze­czy­wi­sto­ści funk­cjo­nu­je rynek opro­gra­mo­wa­nia i nie­ste­ty ‑zwią­za­ny z nim świat zamó­wień publicznych.Nie jest to tyl­ko pro­blem pol­ski, jest to bolącz­ka całej bran­ży. Nic dziw­ne­go, że aż 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie. Walkę z tym pro­ble­mem pod­ję­to już wie­le lat temu. Zamawiane opro­gra­mo­wa­nie, wszę­dzie tam gdzie decy­den­ci są świa­do­mi zagro­żeń, jest mie­rzo­ne. A coraz wię­cej admi­ni­stra­cji pań­stwo­wych jako nor­mę, trak­tu­ją obo­wią­zek wymia­ro­wa­nia opro­gra­mo­wa­nia przed jego zamó­wie­niem. Dobre prak­ty­ki i narzę­dzia będą­ce wyni­kiem tej bata­lii są na wycią­gnię­cie ręki. 

(pier­wot­ne źró­dło jest nie­do­stęp­ne, porów­naj inny mate­riał: https://​www​.com​pu​ter​world​.pl/​n​e​w​s​/​S​k​u​t​e​c​z​n​e​-​m​e​t​o​d​y​-​w​y​m​i​a​r​o​w​a​n​i​a​-​p​r​o​j​e​k​t​o​w​-​I​T​,​4​0​8​5​9​3​.​h​tml)

Ogólnie teza jakiej bro­nią zwo­len­ni­cy tego typu metod brzmi:

moż­li­we jest osza­co­wa­nie pra­co­chłon­no­ści (kosz­tu) wytwo­rze­nia opro­gra­mo­wa­nia wyłącz­nie na bazie wie­dzy o tym, do cze­go ma ono służyć

Innymi sło­wy uwa­ża­my, że na bazie wyma­gań funk­cjo­nal­nych (z regu­ły mowa o przy­pad­kach uży­cia) moż­na osza­co­wać zło­żo­ność apli­ka­cji. Niestety w swo­jej wie­lo­let­niej karie­rze nigdy nie spo­tka­łem się z przy­pad­kiem by wyce­na taka choć zbli­ży­ła się do póź­niej­szych fak­tycz­nych kosz­tów wytwo­rze­nia apli­ka­cji (rzad­kie przy­pad­ko­we zbież­no­ści nie są dowo­dem sku­tecz­no­ści meto­dy). Raczej spo­ty­kam się dość czę­sto z czymś co opi­sa­łem w 2013 roku (tych wycen, zgod­nie z SIWZ, doko­na­no na bazie meto­dy punk­tów funkcyjnych):

Co mnie zasta­na­wia? Przede wszyst­kim to, że ?pro­fe­sjo­nal­ne? fir­my z ogrom­nym (jak twier­dzą na swo­ich stro­nach) doświad­cze­niem, pre­zen­tu­ją ofer­ty opra­co­wa­ne na bazie tej samej doku­men­ta­cji (w koń­cu to prze­targ), a roz­rzut cen tych ofert jest czte­ro­krot­ny!!! ?(Żeliński, 2013)?

Takich przy­pad­ków jest wie­le, i moim zda­niem prak­tycz­nie oba­la­ją tezę o sku­tecz­no­ści tego typu metod (meto­da punk­tów funk­cyj­nych i pokrewne).

Jedną z popu­lar­niej­szych i czę­sto pro­mo­wa­nych metod jest ana­li­za punk­tów funk­cyj­nych pro­mo­wa­na przez International Function Point Users Group (IFPUG). W tej rodzi­ny nale­ży mię­dzy inny­mi COSMIC. Metoda ta bazu­je na dość pro­stych założeniach:

The prin­ci­ples for measu­ring the COSMIC func­tio­nal size of a pie­ce of softwareThe COSMIC method measu­res a size as seen by the ?func­tio­nal users? of the pie­ce of softwa­re to be measu­red, i.e. the sen­ders and/or inten­ded reci­pients of the data that must enter or exit from the softwa­re, respectively.The method uses a model of softwa­re, known as the ?COSMIC Generic Software Model?, which is based on fun­da­men­tal softwa­re engi­ne­ering prin­ci­ples, namely:Functional user requ­ire­ments of a pie­ce of softwa­re can be ana­ly­zed into uni­que func­tio­nal pro­ces­ses, which con­sist of sub-pro­ces­ses. A sub-pro­cess may be either a data move­ment or a data manipulation;Each func­tio­nal pro­cess is trig­ge­red by an ?Entry? data move­ment from a func­tio­nal user which informs the func­tio­nal pro­cess that the func­tio­nal user has iden­ti­fied an event that the softwa­re must respond to;A data move­ment moves a sin­gle data gro­up of attri­bu­tes descri­bing a sin­gle ?object of inte­rest?, whe­re the lat­ter is a ?thing? of inte­rest to a func­tio­nal user;There are four types of data move­ment sub-pro­ces­ses. An ?Entry? moves a data gro­up into the softwa­re from a func­tio­nal user and an ?Exit? moves a data gro­up out. ?Writes? and ?Reads? move a data gro­up to and from per­si­stent sto­ra­ge, respectively.[…]

As an appro­xi­ma­tion for measu­re­ment pur­po­ses (and in light of the appli­ca­bi­li­ty of the method, descri­bed abo­ve), data mani­pu­la­tion sub-pro­ces­ses are not sepa­ra­te­ly measured.

The size of a pie­ce of softwa­re is then defi­ned as the total num­ber of data move­ments (Entries, Exits, Reads and Writes) sum­med over all func­tio­nal pro­ces­ses of the pie­ce of softwa­re. Each data move­ment is coun­ted as one ?COSMIC Function Point? (?CFP?). The size of a func­tio­nal pro­cess, and hen­ce the size of a pie­ce of softwa­re, can be a mini­mum of 2 CFP, with no upper limit. (The COSMIC Software Sizing Methodology. (n.d.). Retrieved May 9, 2019, from COSMIC websi­te: http://​cosmic​-sizing​.org/​c​o​s​m​i​c​-​f​sm/)

(zobacz tak­że opis wdro­żo­nej wer­sji udo­stęp­nio­ny przez ZUS).

Model opi­su­ją­cy fun­da­men­tal­ne zało­że­nia tej meto­dy wyglą­da tak:

źr. http://file.scirp.org/Html/3-9301348_17476.htm
?(?Design of a Performance Measurement Framework for Cloud Computing,? n.d.)?

Generalnie na eta­pie ana­li­zy, bazu­ją­cej na spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych, two­rzo­na jest lista inte­rak­cji z apli­ka­cją Entry/Exit (czy­li tego to co widzi i jest w sta­nie opi­sać przy­szły użyt­kow­nik – lewa stro­na powyż­sze­go mode­lu) i lista ope­ra­cji Write/Read (zapis i odczyt danych, pra­wa stro­na mode­lu). Komponent, któ­ry nazwa­no tu Software, to pewien rodzaj czar­nej skrzyn­ki. Metoda ta po pierw­sze wyma­ga spro­wa­dze­nia wyma­gań do pozio­mu kurio­zal­nie roz­drob­nio­nych przy­pad­ków uży­cia (co opi­sa­łem nie­daw­no w arty­ku­le o pew­nej meto­dzie trans­for­ma­cji pro­ce­su biz­ne­so­we­go na przy­pad­ki uży­cia), po dru­gie zupeł­nie abs­tra­hu­je od wewnętrz­nej zło­żo­no­ści (w naj­now­szej wer­sji tej meto­dy przyj­mu­je się wagi zło­żo­no­ści, nie­ste­ty są one uzna­nio­we). Metoda powsta­ła ponad 30 lat temu, w cza­sach gdy inży­nie­ria opro­gra­mo­wa­nia spro­wa­dza­ła się do maksymy:

dane + funk­cje = oprogramowanie

To jest nie­ste­ty jed­nak pre­hi­sto­ria inży­nie­rii opro­gra­mo­wa­nia. Owszem powsta­je jesz­cze opro­gra­mo­wa­nie w myśl tej mak­sy­my (głów­nie sys­te­mu zarzą­dza­nia wie­dzą), ale nawet śred­nio zło­żo­ne biz­ne­so­we apli­ka­cje, two­rzo­ne jako otwar­te archi­tek­tu­ry obiek­to­we, nie­ste­ty nie pasu­ją do tego wzor­ca”. porów­naj­my powyż­szy model z tym:

Obiektowy model dziedziny Zasada SOLID
Obiektowy model archi­tek­tu­ry apli­ka­cji na bazie wzor­ca BCE, Zasada SOLID (opr. Jarosław Żeliński)

Powyżej dość typo­wa obiek­to­wa archi­tek­tu­ra apli­ka­cji. Kilka wniosków:

  • przy­pa­dek uży­cia nie jest nisko­po­zio­mo­wą funk­cją sys­te­mu”, takie ich defi­nio­wa­nie (nie­zgod­ne z UML) pro­wa­dzi do mon­stru­al­nej zło­żo­no­ści i pra­co­chłon­no­ści już na eta­pie ana­li­zy wymagań,
  • ope­ra­cje zapi­su i odczy­tu danych (repo­zy­to­ria, obiek­ty skraj­nie po pra­wej) w żaden spo­sób nie odzwier­cie­dla­ją zło­żo­no­ści apli­ka­cji, ta tkwi” w kom­po­nen­tach wewnętrz­nych a te nie są zna­ne na tym etapie,
  • wie­le zło­żo­nych ele­men­tów kodu – samo­dziel­ne usłu­gi wewnętrz­ne – nie ma bez­po­śred­nio nic wspól­ne­go ani z zapi­sem danych ani z inte­rak­cja z samą aplikacją,
  • uzna­nie, że moż­na osza­co­wać zło­żo­ność wytwo­rze­nia sys­te­mu tyl­ko na bazie pla­no­wa­nych funk­cjo­nal­no­ści i mode­lu danych moim zda­niem jest nie obrony.

Powyższy model poka­zu­je, że klu­czo­wa zło­żo­ność apli­ka­cji tkwi w czę­ści nazwa­nej w COSMIC softwa­re”, cał­ko­wi­cie pomię­tej w toku pro­wa­dze­nia szacowania.

Model COSMIC (i podob­ne meto­dy) cał­ko­wi­cie abs­tra­hu­je od tego, że apli­ka­cja mogła by powstać na bazie obiek­to­we­go para­dyg­ma­tu i wzor­ców SOLID (w szcze­gól­no­ści otwar­tość na roz­sze­rze­nia przy bra­ku wpro­wa­dza­nia zmian czy­li tak zwa­ne open clo­se prin­ci­ple). Uznanie, że każ­de opro­gra­mo­wa­nie moż­na spro­wa­dzić do pozio­mu ope­ra­cji zapi­su i odczy­tu z logi­ką takich ope­ra­cji umiesz­czo­ną w odwo­ła­niach do bazy danych, cofa nas o 40 lat, do cza­sów metod struk­tu­ral­nych (w tych cza­sach powsta­ła ta meto­da COSMIC). Stowarzyszenie pro­mu­ją­ce meto­dę COSMIC pisze: „… 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie …”, doda­je, że od 40 lat te sta­ty­sty­ki się nie zmie­nia­ją a meto­da ta ma porów­ny­wal­ny czas ist­nie­nia, wiec jak na tym tle oce­nić jej sta­ły roz­wój i domnie­ma­ną skuteczność?

Wielokrotnie widzia­łem, jak budżet i har­mo­no­gram pro­jek­tu wyli­czo­ny na bazie meto­dy punk­tów funk­cyj­nych, był nisz­czo­ny” jed­nym tyl­ko fak­tem roz­po­czę­cia doku­men­to­wa­nia i imple­men­ta­cji raba­to­wa­nia w przy­pad­ku uży­cia” Wystawianie Faktur Sprzedaży. Klasyka nie­ja­ko oba­la­ją­ca sku­tecz­ność tej meto­dy to sys­tem sco­rin­go­wy, któ­re­go prak­tycz­nie cała zło­żo­ność leży poza ope­ra­cja­mi wejścia/wyjścia, a tego rodza­ju pro­ble­mów w tak zwa­nych sys­te­mach biz­ne­so­wych jest bar­dzo wie­le, zary­zy­ku­je nawet tezę, że to typo­we pro­ble­my w obec­nych sys­te­mach wspo­ma­ga­nia zarzą­dza­nia. Metody tego typu, nie raz opar­ta na zbie­ra­nym doświad­cze­niu, są nadal popu­arc­ne .

Jak więc wymia­ro­wać opro­gra­mo­wa­nie? Tu zno­wu pozo­sta­je uczyć się od naj­star­szej dzie­dzi­ny inży­nie­rii czy­li budow­nic­twa: budow­le moż­na wyce­nić tyl­ko na pod­sta­wie pro­jek­tu całej kon­struk­cji (dla apli­ka­cji jest to jej wewnętrz­na archi­tek­tu­ra i logi­ka dzia­ła­nia), na bazie same­go pomy­słu na wiel­ki dom nie da się wyli­czyć ile będzie kosz­to­wa­ło jego posta­wie­nie. Od wie­lu lat mam do czy­nie­nia z ofer­ta­mi skła­da­ny­mi w odpo­wie­dzi na ten sam doku­ment opi­su­ją­cy wyma­ga­nia, roz­rzut wycen (bywa, że o rząd wiel­ko­ści) oba­la każ­dą teo­rię mówią­ca, że jest moż­li­we sen­sow­ne sza­co­wa­nie na tym (przed-pro­jek­to­wym) eta­pie, a wiem, że wie­le z tych wycen jest przy­go­to­wy­wa­nych wła­śnie na bazie metod opar­tych na punk­tach funkcyjnych.

Jedynym sku­tecz­nym spo­so­bem jaki znam i jaki widu­ję w prak­ty­ce, jest wyce­na na bazie pro­jek­tu zawie­ra­ją­ce­go model dzie­dzi­ny sys­te­mu z dokład­nym mode­lem dzia­ła­nia (logi­ki biz­ne­so­wej). Dużo dokład­niej­sze są wyce­ny, doko­ny­wa­ne rela­tyw­nie niskim nakła­dem pra­cy, przez doświad­czo­nych archi­tek­tów opro­gra­mo­wa­nia na bazie co naj­mniej wstęp­nych pro­jek­tów. Wycena na bazie czar­nej skrzyn­ki”, jaką są przy­pad­ki uży­cia dekla­ro­wa­ne” przez zama­wia­ją­ce­go, to raczej wró­że­nie z fusów.


[uzu­peł­nie­nie] Pewną odmia­ną powyż­szej meto­dy (COSMIC) jest meto­da punk­tów funk­cyj­nych IFPUG (z International Function Point Users Group). Oparta jest dekla­ro­wa­nych funk­cjo­nal­no­ściach i zbie­ra­nych danych histo­rycz­nych ze zre­ali­zo­wa­nych pro­jek­tów. Pomysł pole­ga na uzna­niu, że kosz­ty imple­men­ta­cji podob­nych funk­cji sys­te­mu” są tak­że podobne. 

Niestety to zało­że­nie nie znaj­du­je potwier­dze­nia w prak­ty­ce a twór­cy meto­dy sami przy­zna­ją, że jej sku­tecz­ność jest niska .

Podręcznik Stosowania meto­dy Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa (2018)

Powyższe to wstęp do pew­ne­go ofi­cjal­ne­go doku­men­tu. Konia z rzę­dem temu kto okre­śli poję­cie funk­cjo­nal­no­ści biz­ne­so­wej usłu­gi apli­ka­cji i jej licz­bę jed­no­stek, nie widząc jak będzie reali­zo­wa­na. Prosty przy­kład: apli­ka­cja dla Biblioteki (patrz: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? pro­jekt badaw­czy) ma mieć funk­cjo­nal­ność «wypo­ży­cze­nie książ­ki» i «zwrot książ­ki», rzecz w tym, że naj­lep­sza spraw­dzo­na imple­men­ta­cja to nie będą dwie funk­cje” tyl­ko jed­na for­mat­ka ekra­no­wa Karta Wypożyczenia a zwrot książ­ki będzie reali­zo­wa­ny poprzez wpi­sa­nie daty zwro­tu na wysta­wio­nej wcze­śniej Karcie Wypożyczenia. W tym momen­cie wymia­ro­wa­nie IFPUG (COSMIC tak­że) jest po pro­stu fun­ta kła­ków war­te: będzie potęż­nie zawy­żo­ne, a deve­lo­per – pod dyk­tan­do takiej wyce­ny – wyko­na bar­dzo złą i kosz­tow­ną imple­men­ta­cję. Innym powo­dem niskiej wia­ry­god­no­ści tego typu metod jest to, że na eta­pie w któ­rym zna­my przy­pad­ki uży­cia a nie zna­my ich imple­men­ta­cji nie mam pod­staw do oce­ny zło­żo­no­ści bo nie wie­my ile będzie sce­na­riu­szy dla każ­de­go przy­pad­ku uży­cia a może ich być wię­cej niż jeden (patrz Use Case 2.0). Po trze­cie jakość mode­lu przy­pad­ków uży­cia też ma ogrom­ny wpływ na tak­że wyce­nę (patrz Przypadki uży­cia i ich deta­le).

Generalnie moż­na pod­su­mo­wać to tak: meto­dy wyce­ny bazu­ją­ce na sta­ty­sty­kach pocho­dzą­cych ze zre­ali­zo­wa­nych pro­jek­tów są opar­te na zało­że­niu, że wyce­nia­ny pro­jekt będzie reali­zo­wa­ny tymi samy­mi lub ana­lo­gicz­ny­mi meto­da­mi co samo z sie­bie jest zaprze­cze­niem postę­pu tech­nicz­ne­go i roz­wo­ju metod inży­nie­rii opro­gra­mo­wa­nia. Praktyka poka­zu­je, że wyce­ny tymi meto­da­mi są prak­tycz­nie pra­wie zawsze zawy­żo­ne a obsza­ry nowa­tor­skie moc­no nie­do­sza­co­wa­ne lub prze­sza­co­wa­ne (bo nowa funk­cjo­nal­ność z zasa­dy nie ma histo­rii). W efek­cie moż­na pod­su­mo­wać to tak: meto­dy sta­ty­stycz­ne wymia­ro­wa­nia, opar­te na przy­pad­kach uży­cia lub funk­cjo­nal­no­ściach, to meto­dy opar­te na pre­dyk­cji histo­rycz­nych danych pro­jek­to­wych, gdzie mate­ria­łem wej­ścio­wym jest model czar­nej skrzyn­ki. Jeżeli do tego doda­my infor­ma­cję o jako­ści reali­za­cji pro­jek­tów infor­ma­tycz­nych publi­ko­wa­ne cyklicz­nie przez Standish Group:

To wnio­sek jaki się nasu­wa to: sto­so­wa­nie metod sta­ty­stycz­nych, zawy­ża­ją­cych wyce­ny, beto­nu­je kata­stro­fal­ny stan opi­sa­ny w tych rapor­tach. Alternatywą jest pro­ces MDA/SPEM, któ­ry zakła­da, że wyce­na będzie doko­ny­wa­na dopie­ro po opra­co­wa­niu co naj­mniej wstęp­ne­go pro­jek­tu imple­men­ta­cji usług apli­ka­cji (przy­pad­ki uży­cia), co nie tyl­ko uwia­ry­god­ni wyce­nę ale tak­że roz­wią­że wie­le wąt­pli­wo­ści na tym wcze­snym etapie. 

(arty­kuł uzu­peł­nio­ny w 2021 r.)

Źródła

Czarnacka-Chrobot, B. (2009). WYMIAROWANIE FUNKCJONALNE PRZEDSIĘWZIĘĆ ROZWOJU SYSTEMÓW OPROGRAMOWANIA WSPOMAGAJĄCYCH ZARZĄDZANIE NA BAZIE UOGÓLNIONYCH DANYCH HISTORYCZNYCH. 13.
Pospieszny, P., Czarnacka-Chrobot, B., & Kobyliński, A. (2015). Application of Function Points and Data Mining Techniques for Software Estimation – A Combined Approach. In A. Kobyliński, B. Czarnacka-Chrobot, & J. Świerczek (Eds.), Software Measurement (Vol. 230, pp. 96 – 113). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 24285-9_7
Bautista, L., Abran, A., & April, A. (2012). Design of a Performance Measurement Framework for Cloud Computing. 2012. https://​doi​.org/​1​0​.​4​2​3​6​/​j​s​e​a​.​2​0​1​2​.​5​2​011

UML version 2.5

Co praw­da for­mal­na publi­ka­cja wer­sji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie uto­nie (spo­koj­ne prze­brnię­cie tych 794 stron wyma­ga cza­su i cier­pli­wo­ści), czy­li wzmian­ka i kil­ka słów z pierw­szych wra­żeń. Specyfikacja do pobra­nia tu:

Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5

Zdaję sobie spra­wę z tego, że poniż­sze nie wszyst­kim z Was wszyst­ko wyja­śni ale ten aku­rat wpis adre­su­ję dla tych z Was, któ­rzy korzy­sta­ją już z UML, nawet w bar­dzo pro­sty sposób.

Wersja 2.5 UML to wer­sja chy­ba prze­ło­mo­wa, bo:

  • zre­zy­gno­wa­no w koń­cu z podzia­łu na dwie czę­ści Infrastructure i Superstructure,
  • upo­rząd­ko­wa­no cały sys­tem poję­cio­wy nota­cji: jest to w koń­cu jed­na w peł­ni spój­na nota­cja (sys­tem kla­sy­fi­ka­to­rów, kie­dyś Infrastructure) oraz zestaw pre­de­fi­nio­wa­nych grup ste­reo­ty­pów z ich dedy­ko­wa­ną seman­ty­ką i syn­tak­ty­ką (kie­dyś Superstructure).
  • dia­gram jako poję­cie, obec­nie sta­no­wi jedy­nie kon­tekst a nie, jak kie­dyś zamknię­tą sub­no­ta­cję” (UML zaczy­nał w latach 90-tych jako zle­pek kil­ku nota­cji trzech autorów).

Obecnie mamy osiem typów dia­gra­mów (kopia z oryginału):

UML dia­grams may have the fol­lo­wing kinds of fra­me names as part of the heading:
? acti­vi­ty
? class
? com­po­nent
? deploy­ment
? inte­rac­tion
? pac­ka­ge
? sta­te machi­ne
? use case
In addi­tion to the long form names for dia­gram heading types, the fol­lo­wing abbre­via­ted forms can also be used:
? act (for acti­vi­ty fra­mes)
? cmp (for com­po­nent fra­mes)
? dep (for deploy­ment fra­mes)
? sd (for inte­rac­tion fra­mes)
? pkg (for pac­ka­ge fra­mes)
? stm (for sta­te machi­ne fra­mes)
? uc (for use case frames)

Jak widać, trzy­li­tro­wych skró­tów ozna­cza­ją­cych dia­gra­my jest o jeden mniej (sie­dem). To wyni­ka z tego, że wszyst­kie dia­gra­my w UML to tak na praw­dę dia­gra­my klas (ten typ dia­gra­mu nie ma swo­je­go dedy­ko­wa­ne­go skró­tu), z tym że sta­no­wią one kon­tek­sto­we pro­fi­le. Struktura poję­cio­wa tych dia­gra­mów (ich [[tak­so­no­mia]]):

UML The taxonomy of structure and behavior diagrams

W sto­sun­ku do UML 2.4 dia­gram pro­fi­lu jest teraz rów­no­praw­nym typem dia­gra­mu (czter­na­sty). Wszystkie poję­cia UML (con­structs) zosta­ły przy­dzie­lo­ne kon­tek­sto­wo to typów diagramów:

The con­structs con­ta­ined in each of the UML dia­grams are descri­bed in the clau­ses indi­ca­ted below.
? Activity Diagram – Activities
? Class Diagram – Structured Classifiers
? Communication Diagram – Interactions
? Component Diagram – Structured Classifiers
? Composite Structure Diagram – Structured Classifiers
? Deployment dia­gram – Deployments
? Interaction Overview Diagram – Interactions
? Object Diagram – Classification
? Package Diagram – Packages
? Profile Diagram – Packages
? State Machine Diagram – State Machines
? Sequence Diagram – Interactions
? Timing Diagram – Interactions
? Use Case Diagram – Use Cases

Należy to rozu­mieć w ten spo­sób: dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py acti­vi­ties” (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla kla­sy­fi­ka­to­rów struk­tu­ral­nych”, itd.

Warto przy­pa­trzeć się swo­im narzę­dziom CASE, gdyż nie­ste­ty nie wszyst­kie mają wbu­do­wa­ny powyż­szy kla­so­wy” para­dyg­mat (w UML wszyst­ko jest kla­są). Wiele z nich nadal hoł­du­je zasa­dzie dia­gra­my jako odręb­ne nota­cje, obec­nie w UML w każ­dym typie dia­gra­mu moż­na użyć każ­de­go ele­men­tu nota­cji, dia­gram jako poję­cie to wyłącz­nie kon­te­ner nio­są­cy głów­ny kon­tekst dane­go mode­lu, bo przy­po­mi­nam, że dia­gram w UML to wyłącz­nie widok cało­ści lub czę­ści mode­lu z okre­ślo­nej per­spek­ty­wy i na okre­ślo­nym pozio­mie abstrakcji.

[uzu­peł­nie­nie 2015-11-21] Z pew­ną satys­fak­cją odkry­łem” (pier­wot­nie, pisząc ten arty­kuł mie­siąc temu, nie zwró­ci­łem na to uwa­gi), że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji, zwa­nej w czę­ści lite­ra­tu­ry sła­bą kom­po­zy­cją”. Ta kurio­zal­na kon­struk­cja poję­cio­wa kłó­ci­ła się z poję­ciem i aso­cja­cji jako takiej i kom­po­zy­cji jako związ­ku całość część”. Nie ja jeden, jak śle­dzę dys­ku­sje człon­ków OMG na listach LinkedIn, dekla­ro­wa­łem, że nie rozu­miem” czym jest agre­ga­cja (chy­ba pierw­szym, któ­ry to gło­śno mówił był Martin Fowler). Na szczę­ście widać, że defi­ni­cja tego poję­cia nie wytrzy­ma­ła boju z logi­ką. Co praw­da sym­bol aso­cja­cji z pustym rom­bem” jest (tyl­ko) na liście sym­bo­li w dodat­ku B.6 (str. 718) jed­nak widać, że to relikt kom­pa­ty­bil­no­ści wstecz, w tre­ści całej spe­cy­fi­ka­cji to poję­cie nie jest w ogó­le uży­wa­ne. Generalnie mamy zwią­zek kom­po­zy­cji (peł­ny romb), a ele­ment skom­po­no­wa­ny może być rze­czy­wi­sty (part) lub abs­trak­cyj­ny (patrz rozdz. 11.2.3.2 Parts and Roles oraz 11.2.3.3 Connectors). Podobnie z dzie­dzi­cze­niem: nie ma dzie­dzi­cze­nia (korek­ta gru­dzień 2017, UML 2.5.1.).

Polecam całą spe­cy­fi­ka­cję, znacz­nie krót­sza od poprzedniej :).