„Jeśli myślisz, że dobra archi­tek­tu­ra jest dro­ga, spró­buj złej”

Wstęp

W roku 2008 pisa­łem (Forbs):

W wie­lu fir­mach decy­zja o wdro­że­niu sys­te­mu infor­ma­tycz­ne­go bar­dzo czę­sto nie jest poprze­dzo­na żad­ny­mi przy­go­to­wa­nia­mi w rodza­ju oce­ny struk­tu­ry orga­ni­za­cji, jej zdol­no­ści do zmian czy też upo­rząd­ko­wa­niem obie­gu infor­ma­cji. Częstym grze­chem jest pró­ba ?wtło­cze­nia? w sys­tem infor­ma­tycz­ny ?sta­re­go? porząd­ku. Drugi grzech to brak opi­sa­ne­go sys­te­mu infor­ma­cyj­ne­go. W efek­cie nastę­pu­je zde­rze­nie rygo­rów papie­ro­we­go obie­gu infor­ma­cji z obie­giem danych w sys­te­mie infor­ma­tycz­nym. Rezygnacja z wie­lu czyn­no­ści (np. sta­wia­nie pie­czą­tek i pod­pi­sów) lub zamia­ny ich na inne sta­je się klu­czo­wym, bro­nio­nym jak nie­pod­le­gło­ści przez wie­lu kie­row­ni­ków obsza­rem. Dzieje się tak w sytu­acji gdy postrze­ga­ją oni swo­ją wła­dzę i kie­row­ni­czą rolę wła­śnie w tych gadże­tach jaki­mi są pie­cząt­ki. Dlaczego tak się dzieje?

System infor­ma­cyj­ny to nie infor­ma­ty­ka, kto o tym zapo­mi­na – prze­gry­wa – FORBES w Marcu 2008 roku, numer 3/2008 na stro­nie 117

Oprogramowanie wspo­ma­ga­ją­ce zarzą­dza­nie fir­mą sta­no­wi sobą pod­sys­tem w sys­te­mie jakim jest orga­ni­za­cja, o czym pisa­łem niedawno: 

Z per­spek­ty­wy orga­ni­za­cji i ryn­ku, opro­gra­mo­wa­nie wbu­do­wa­ne to jest to opro­gra­mo­wa­nie, któ­re­go uży­wa się wewnątrz fir­my ale któ­re­go nie widzą, nie mają z nim kon­tak­tu, klien­ci tej firmy.

(https://​it​-con​sul​ting​.pl/​2​0​2​3​/​0​2​/​2​7​/​o​r​g​a​n​i​z​a​c​j​a​-​j​a​k​o​-​m​e​c​h​a​n​i​z​m​-​c​z​y​l​i​-​s​l​o​n​-​w​-​p​o​k​o​ju/)

Organizacje to sys­tem infor­ma­cyj­ny i sys­tem infor­ma­tycz­ny jako jego pod­sys­tem. Mamy więc dwie odręb­ne archi­tek­tu­ry z per­spek­ty­wy oprogramowania:

1. archi­tek­tu­ra infor­ma­cji, czy­li reali­za­cja wyma­gań funk­cjo­nal­nych (komu, do cze­go i jakie infor­ma­cje są potrzebne),
2. archi­tek­tu­ra tech­nicz­na śro­do­wi­ska, czy­li gdzie są prze­twa­rza­ne dane, oraz wyma­ga­nia poza­funk­cjo­nal­ne (jak spraw­ny, nie­za­wod­ny i bez­piecz­ny ma być ten system).

Są to skraj­nie odręb­ne obsza­ry inży­nie­rii, a mimo to sta­le widzę w pro­jek­tach tyl­ko jed­ne­go ​„archi­tek­ta”, z regu­ły jest to dru­gi, pierw­sze­go nie ma (patrz tak­że: SYSTEM INFORMACYJNY A SYSTEM INFORMATYCZNY). Niestety typo­wa poraż­ka pro­jek­tów IT to ​„sys­tem pra­cu­je szyb­ko i nie­za­wod­nie ale w zasa­dzie nadal do nicze­go nam nie służy”.

Ten tekst to pró­ba wska­za­nia kolej­nej przy­czy­ny niskiej sku­tecz­no­ści pro­jek­tów w obsza­rze inży­nie­rii opro­gra­mo­wa­nia. Hipotezą jest teza mówią­ca, że: przy­czy­ną (jed­ną z) jest bez­po­śred­nie anga­żo­wa­nie kom­pe­ten­cji tech­no­lo­gicz­nych do roz­wią­zy­wa­nia pro­ble­mów nie-tech­no­lo­gicz­nych, jaki­mi są prze­pływ i prze­twa­rza­nie infor­ma­cji w orga­ni­za­cji, myl­nie utoż­sa­mia­ne z prze­twa­rza­niem danych.

Troszkę teorii

Fundamentem tego tek­stu jest tak zwa­ny Trójkąt Ullmana opi­su­ją­cy zwią­zek mię­dzy rze­czą, poję­ciem (nazwą) repre­zen­tu­ją­cą tę rzecz, oraz defi­ni­cją tego poję­cia .

Kluczem jest tu roz­róż­nie­nie pojęć: dane, infor­ma­cja, przed­miot . Istotą pro­ble­mu jest czło­wiek i jego myśl: trój­kąt Ullmana opi­su­je te trzy poję­cia i związ­ki mię­dzy nimi.

Powyżej (po lewej) ory­gi­nal­ny Trójkąt Ullmana oraz (po pra­wej) ilu­stra­cja poka­zu­ją­ca miej­sce czło­wie­ka w tym trój­ką­cie. Trójkąt ten opi­su­je mecha­nizm komu­ni­ka­cji mię­dzy ludź­mi, czy­li to czym jest, i jak jest, prze­ka­zy­wa­na infor­ma­cja. Pokazano to poniżej:

1. czło­wiek zoba­czył rzecz (poma­rań­cza), ​„wie” co zoba­czył (potra­fi to wyra­zić w języ­ku jakim włada),
2. zapi­sał (opi­sał) to co zoba­czył czy­li utrwa­lił opis, 
3. inny czło­wiek (lub on sam po jakimś cza­sie) odczy­tał zapis.

Komunikacja pole­ga na prze­ka­zy­wa­niu infor­ma­cji mię­dzy ludź­mi: mię­dzy nadaw­cą a odbior­cą. Język (sło­wa wypo­wia­da­ne lub pismo jako ich repre­zen­ta­cja) umoż­li­wia ten prze­kaz. Komunikatem może by jed­no sło­wo (poję­cie) tak jak na powyż­szym sche­ma­cie. Jednak jako ludzie sto­su­je­my bar­dziej wyra­fi­no­wa­na for­mę komu­ni­ka­wa­nia o czymś: są to zda­nia, np.:

Widziałem poma­rań­czę.

Jest to komu­ni­kat, mówią­cy o tym, że nadaw­ca widział poma­rań­cze. Jako ludzie wła­da­ją­cy okre­ślo­nym języ­kiem, rozu­mie­my co zna­czy sło­wo «poma­rań­cza» i sło­wo «widzia­łem». W powyż­szym zda­niu sło­wo «poma­rań­cza» jest poję­ciem wska­zu­ją­cym na przed­miot (lub kolor poma­rań­czo­wy), zaś sło­wo «widzia­łem» ozna­cza «zoba­czo­no» (albo «zosta­ła zoba­czo­na»). Słowo «zoba­czo­no» jest pre­dy­ka­tem czy­li związ­kiem zda­nio­twór­czym. Predykat jest wyma­ga­ny do zro­zu­mie­nia o jaki fakt cho­dzi, bo samo wypo­wie­dzia­ne sło­wo «poma­rań­cza» nie nie­sie infor­ma­cji. Ale zda­nie ​„Widziałem poma­rań­czę” infor­mu­je nas o tym do cze­go doszło. 

Zdania (komu­ni­ka­ty) moż­na wyra­zić w posta­ci utrwa­lo­nej czy­li w posta­ci doku­men­tu. Dokumentem jest zda­nie ​„Widziałem poma­rań­czę”, moż­li­we do utrwa­le­nia na jakim­kol­wiek nośni­ku (tak­że elek­tro­nicz­nym), czy­li moż­li­we do zapi­sa­nia, a do tego są nie­zbęd­ne zna­ki czy­li np. pismo lub iko­ny. Więcej o zda­niach i onto­lo­gii w arty­ku­le: Ontologia – zasto­so­wa­nie w inży­nie­rii opro­gra­mo­wa­nia.

Maszyna nie rozu­mie zdań, któ­re rozu­mie czło­wiek, ale maszy­na może prze­twa­rzać dane (zna­ki). Dlatego dla potrzeb prze­twa­rza­nia danych (a nie infor­ma­cji, bo to potra­fi tyl­ko rozum­ny czło­wiek) sto­su­je­my inna for­mę: for­mu­la­rze. Zdanie ​„Widziałem poma­rań­czę” moż­na zapi­sać tak:

Zdanie ​„Widziałem poma­rań­czę” moż­na roz­wi­nąć: ​„Ja, Jarek Żeliński, 1 kwiet­nia 2023 roku, w skle­pie ABC, widzia­łem poma­rań­czę”. Można to zapi­sać w posta­ci moż­li­wej do prze­twa­rza­nia maszynowego:

Jeżeli potra­fi­my opi­sać regu­ły prze­twa­rza­nia danych, czy­li mecha­nizm wytwo­rze­nia nowych tre­ści na pod­sta­wie już ist­nie­ją­cych, to zna­czy, że potra­fi­my na pod­sta­wie zada­nia o tym co zamó­wio­no wyge­ne­ro­wać zda­nie o tym co sprze­da­no. Albo: na pod­sta­wie Zamówienia potra­fi­my wyge­ne­ro­wać Fakturę.

Dlatego ma sens by w kodzie apli­ka­cji poja­wi­ła się kla­sa Faktura, ale nie ma sen­su by w tym kodzie poja­wi­ła się kla­sa Sprzedawca. 

Architektura systemu

Każdy sys­tem to jego archi­tek­tu­ra i reak­cje na bodź­ce. Architektura to sku­tek wie­lu lat doświad­czeń w posta­ci dobrych prak­tyk i wzor­ców pro­jek­to­wych. Zaprojektowanie wyso­kiej jako­ści archi­tek­tu­ry nie jest pro­ble­mem dla oso­by zna­ją­cej i rozu­mie­ją­cej te wzor­ce. Powiązanie wyma­gań, usług apli­ka­cji i jej archi­tek­tu­ry zbu­do­wa­nej na wzor­cach moż­na ogól­nie przed­sta­wić jak poniżej:

Pozostaje rzecz naj­trud­niej­sza: zro­zu­mieć czym są infor­ma­cje i zor­ga­ni­zo­wać dane oraz ich prze­twa­rza­nie oraz zde­kom­po­no­wać pro­blem (patrz refe­rat: Can Great Programmers Be Taught? – John Ousterhout). W dal­szej czę­ści omó­wio­no infor­ma­cje i prze­twa­rza­nie danych. Kwestię dekom­po­zy­cji i pro­jek­to­wa­nia prze­twa­rza­nia danych opi­sa­łem nie­daw­no w arty­ku­le o pro­ce­sie ICONIX.

System informacyjny vs. informatyczny

Przypomnijmy defi­ni­cję: poję­cie sys­tem, któ­ry jest naj­czę­ściej defi­nio­wa­ne jako:

zespół wza­jem­nie sprzę­żo­nych ele­men­tów, speł­nia­ją­cy okre­ślo­ną funk­cję i trak­to­wa­ny jako wyod­ręb­nio­ny z oto­cze­nia w okre­ślo­nym celu

Tym razem chcę zwró­cić uwa­gę na to, że sys­te­mo­we meto­dy ana­li­zy i opty­ma­li­za­cji orga­ni­za­cji nie róż­nią sie od metod ana­li­zy i pro­jek­to­wa­nia sys­te­mów infor­ma­cyj­nych i infor­ma­tycz­nych. Jednak jest istot­na dzie­dzi­no­wa róż­ni­ca mię­dzy sys­te­mem infor­ma­cyj­nym a infor­ma­tycz­nym :

• sys­tem infor­ma­cyj­ny to sys­tem, któ­re­go ele­men­ta­mi są infor­ma­cja i człowiek,
• sys­tem infor­ma­tycz­ny to sys­tem, któ­re­go ele­men­ta­mi są dane oraz urzą­dze­nia wyko­rzy­sta­ne do ich prze­sy­ła­nia, pre­zen­ta­cji i przetwarzania.

Jeżeli okre­ślo­ny ele­ment sys­te­mu potrak­tu­je­my jako jego pod­rzęd­ny sys­tem (pod-sys­tem), poja­wia się poję­cie: sys­tem sys­te­mów. Innymi sło­wy sys­tem może mieć pod­sys­te­my, może też więc być ele­men­tem sys­te­mu nad­rzęd­ne­go (sys­tem nad­rzęd­ny jest tu oto­cze­niem bazo­we­go sys­te­mu) . W języ­ku angiel­skim jest to «infor­ma­tion sys­tems» vs «infor­ma­tion tech­no­lo­gy» .

Model systemu

Model sys­te­mu jest czę­sto obra­zo­wa­ny jak poniżej:

Na sche­ma­cie tym:

• «Requirements» to ocze­ki­wa­ne zewnętrz­ne cechy sys­te­mu gdy jest to pro­jekt sys­te­mu, lub wyja­śnia­ne zacho­wa­nia gdy jest to ana­li­za sys­te­mu ist­nie­ją­ce­go (bada­ne­go),
• «Structure» to archi­tek­tu­ra ele­men­tów systemu,
• «Behavior» to wza­jem­ne oddzia­ły­wa­nia ele­men­tów sys­te­mu i sce­na­riu­sze reak­cji sys­te­mu na bodź­ce z zewnątrz (z otoczenia),
• wszyst­kie trzy są ze sobą powią­za­ne pojęciowo. 

Jeżeli zgo­dzi­my się z tezą, że «sys­tem infor­ma­tycz­ny» prze­twa­rza infor­ma­cje a nie odwrot­nie, to zna­czy że «sys­tem infor­ma­cyj­ny» jest nad­rzęd­ny dla tego sys­te­mu. Innymi sło­wy, «sys­tem infor­ma­tycz­ny» jest co do zasa­dy pod­sys­te­mem «sys­te­mu informacyjnego».

Organizacja jako system

Informacje to dome­na ludzi, któ­rzy inte­pre­tu­ją dane, te zaś są utrwa­la­ne i prze­no­szo­ne jako doku­men­ty. Dokument to okre­ślo­na i nazwa­na treść mają­ca okre­ślo­na struk­tu­rę . Dokument z per­spek­ty­wy sys­te­mu infor­ma­cyj­ne­go, to komu­ni­kat z per­spek­ty­wy sys­te­mu infor­ma­tycz­ne­go .

Modele pro­ce­sów biz­ne­so­wych budu­je­my na bazie tezy i defi­ni­cji mówią­cej, że pro­ces to aktyw­ność zwień­czo­na jej pro­duk­tem. Z per­spek­ty­wy mode­li ana­li­tycz­nych w nota­cji BPMN, wyj­ścia aktyw­no­ści to doku­men­ty (DataObject) .

Komputery i opro­gra­mo­wa­nie to tech­ni­ka i tech­no­lo­gia, któ­re mode­lu­je­my z uży­ciem nota­cji UML . Tu ope­ru­je­my poję­cia­mi kom­po­nen­tów i danych, któ­re te kom­po­nen­ty prze­twa­rza­ją, prze­sy­ła­ją i pre­zen­tu­ją ludziom.

Oba te obsza­ry łączą się: «sys­tem infor­ma­cyj­ny» jest wspie­ra­ny «sys­te­mem infor­ma­tycz­nym» (dru­gi jest ele­men­tem pierw­sze­go). Jak? Poniżej jeden w wie­lu przy­kła­dów defi­nio­wa­nia tak zwa­nej Architektury zorien­to­wa­nej na usłu­gi (ang. SOA, Service-orien­ted Architecture):

Najwyżej jest war­stwa pro­ce­sów biz­ne­so­wych (Business Processes). Tu ope­ru­je­my poję­cia­mi: aktyw­ność, doku­ment, rola/osoba. Jest to poziom sys­te­mu infor­ma­cyj­ne­go. Jeżeli chce­my zde­fi­nio­wać wyma­ga­nia na sys­tem infor­ma­tycz­ny (lub opi­sać ist­nie­ją­cy), two­rzy­my listę punk­tów, w któ­rych «sys­tem infor­ma­tycz­ny» wspie­ra «sys­tem informacyjny». 

Mówimy, że «sys­tem infor­ma­tycz­ny» świad­czy usłu­gi «sys­te­mo­wi infor­ma­cyj­ne­mu». Business Services to abs­trak­cyj­na war­stwa spe­cy­fi­ko­wa­nia tych usług (zależ­nie od kon­tek­stu: ist­nie­ją­cych lub wymaganych).

«System infor­ma­tycz­ny» to łącz­nie kom­po­nen­ty apli­ka­cyj­ne (Components) oraz infra­struk­tu­ra w jakiej one funk­cjo­nu­ją (Operational Resources). Jest to war­stwa infra­struk­tu­ry technicznej.

Mechanizm czyli logika działania systemu

Generalnie poję­cie mecha­nizm to wyja­śnie­nie powsta­wa­nia obser­wo­wa­nych fak­tów. Opis mecha­ni­zmu moż­na wyra­zić wzo­ra­mi mate­ma­tycz­ny­mi, sche­ma­ta­mi blo­ko­wy­mi, algo­ryt­ma­mi, pro­ce­du­ra­mi, okre­ślo­ny­mi zasa­da­mi, zwa­ny­mi tu regu­ła­mi biz­ne­so­wy­mi .

Mechanizm ten to dane upo­rząd­ko­wa­ne w struk­tu­ry jaki­mi są doku­men­ty oraz zasa­dy prze­pły­wu tych doku­men­tów i prze­kształ­ca­nia jed­nych w dru­gie. Przepływ pra­cy oraz two­rze­nie i prze­pływ doku­men­tów mode­lu­je­my jako jak pro­ce­sy biz­ne­so­we (BPMN). Struktury tych doku­men­tów mode­lu­je­my jako agre­ga­ty (UML, XML). Reguły biz­ne­so­we to zasa­dy okre­śla­ją­ce te prze­pły­wy oraz popraw­ność tre­ści doku­men­tów. Wykonawcami są ludzie wspie­ra­nie narzę­dzia­mi (opro­gra­mo­wa­nie czy­li sys­tem informatyczny).

Z powyż­sze­go wywo­du nasu­wa­ją sie wnioski:

1. «sys­tem infor­ma­cyj­ny» i «sys­tem infor­ma­tycz­ny» to dwa odręb­ne obsza­ry dziedzinowe,
2. ich ana­li­zy i pro­jek­to­wa­nie to tak­że dwie odręb­ne dziedziny,
3. sko­ro «sys­tem infor­ma­tycz­ny» to część nad­rzęd­ne­go sys­te­mu jakim jest «sys­tem infor­ma­cyj­ny» to wszel­kie dzia­ła­nia doty­czą­ce «sys­te­mu infor­ma­tycz­ne­go» powin­ny być poprze­dzo­ne ana­li­zą «sys­te­my informacyjnego»,
4. sko­ro «sys­tem infor­ma­cyj­ny» to tak­że mecha­nizm jego dzia­ła­nia, to dostaw­ca (wyko­naw­ca) «sys­te­mu infor­ma­tycz­ne­go» powi­nien wyko­nać imple­men­ta­cje tego mecha­ni­zmu (po jego udo­ku­men­to­wa­niu) a nie pro­jek­to­wać go, bo «sys­tem infor­ma­cyj­ny» ist­nie­je, nale­ży go prze­ana­li­zo­wać, zro­zu­mieć i opisać.

Analiza i pro­jek­to­wa­nie sys­te­mów infor­ma­cyj­nych to ele­ment ana­li­zy sys­te­mo­wej orga­ni­za­cji. Wynikiem tej ana­li­zy jest logi­ka two­rze­nia i prze­twa­rza­nia infor­ma­cji w orga­ni­za­cji, te infor­ma­cje są zapi­sy­wa­ne i prze­twa­rza­ne w sys­te­mach infor­ma­tycz­nych jako dane. Dlatego naj­pierw nale­ży wyko­nać ana­li­zę sys­te­mu infor­ma­cyj­ne­go orga­ni­za­cji, jej pro­duk­tem powi­nien być opis (model) mecha­ni­zmu prze­twa­rza­nia infor­ma­cji w orga­ni­za­cji. Dopiero dru­gim kro­kiem może wybór i wdro­że­nie (zle­ce­nie wyko­na­nia) opro­gra­mo­wa­nia, czy­li zle­ce­nie imple­men­ta­cje okre­ślo­nej czę­ści sys­te­mu infor­ma­cyj­ne­go. Praktyka poka­zu­je, że każ­da dro­ga na skró­ty (pomi­nię­cie eta­pu ana­li­zy sys­te­mu infor­ma­cyj­ne­go) koń­czy się źle.

Opisany na począt­ku sze­ścian to zarów­no model całej orga­ni­za­cji, jak i model każ­de­go jej pod­sys­te­mu. Można sobie wyobra­zić, że taki sze­ścian zawie­ra w sobie wie­le mniej­szych, każ­dy opi­su­ją­cy okre­ślo­ny pod­sys­tem w organizacji.

Wymiana danych a wymiana informacji – współpraca organizacji

Na tym tle war­to tak­że pod­su­mo­wać kwe­stie współ­pra­cy orga­ni­za­cji czy­li wymia­ny infor­ma­cji i wymia­ny danych. Jeżeli uzna­my, że orga­ni­za­cja to ludzie i wspie­ra­ją­ce ich narzę­dzia, to współ­pra­ca orga­ni­za­cja odby­wa się w dwóch dome­nach: infor­ma­cyj­nej i informatycznej: 

Z powyż­sze­go nasu­wa się klu­czo­wy wniosek: 

pro­jek­to­wa­nie współ­pra­cy firm wyma­ga naj­pierw ana­li­zy i udo­ku­men­to­wa­nia mode­lu infor­ma­cyj­ne­go: jakie i o czym infor­ma­cje są wymie­nia­ne, a potem dopie­ro moż­na pro­jek­to­wać sys­tem infor­ma­tycz­ny wspie­ra­ją­cy tę współ­pra­cę w posta­ci wymia­ny danych. 

Jako ludzie rozu­mie­my to co czy­ta­my i na pod­sta­wie tego podej­mu­je­my decy­zje. Jednak kom­pu­ter ​„nie rozu­mie” danych, dla­te­go prze­nie­sie­nie jakiej­kol­wiek czę­ści «prze­twa­rza­nia infor­ma­cji» do «sys­te­mu infor­ma­tycz­ne­go» wyma­ga opi­sa­nia jej w posta­ci struk­tur danych i reguł ich prze­twa­rza­nia. Najefektywniejszą meto­dą jest spro­wa­dze­nie infor­ma­cji do posta­ci skoń­czo­nej licz­by doku­men­tów oraz zbu­do­wa­nie listy reguł opi­su­ja­cych związ­ki mię­dzy nimi .

Architektura sys­te­mu jest łatwa do zapro­jek­to­wa­nia jak ktoś zna i rozu­mie archi­tek­to­nicz­ne wzor­ce pro­jek­to­we i dobre prak­ty­ki (ale te aktu­al­ne, a nie te z przed 40 lat, na bazie któ­rych powsta­ły mię­dzy inny­mi obec­ne mono­li­ty ERP).

Low-code i No-code

Powszechnie uwa­ża się, że 

No code jest fascy­nu­ją­cym kie­run­kiem, któ­ry zna­czą­co przy­spie­sza roz­wój apli­ka­cji i wpro­wa­dza rewo­lu­cyj­ne zmia­ny w bran­ży IT. To nie­sa­mo­wi­te, jakie moż­li­wo­ści otwie­ra­ją się dla osób biz­ne­so­wych i pro­gra­mi­stów, umoż­li­wia­jąc im wspól­ne two­rze­nie apli­ka­cji z mniej­szym nakła­dem cza­su i kodowania.

(wypo­wiedź na LinkedIn)

Zgadzam się w tym, jed­nak pro­ble­mem nie jest kodo­wa­nie, pro­ble­mem jest zro­zu­mie­nie tego jakie infor­ma­cje, o czym i dla­cze­go są (mają być) prze­twa­rza­ne, jak je zapi­sać jako dane w sys­te­mie i jak prze­twa­rzać. Narzędzia low-code i no-code zna­czą­co przy­śpie­sza­ją imple­men­ta­cją, ale nie zastę­pu­ją ana­li­zy i projektowania. 

Podsumowanie

Z powyż­sze­go nasu­wa­ją się tak­że pro­ste i oczy­wi­ste wnioski:

1. nie ma żad­ne­go sen­su pro­jek­to­wa­nie «sys­te­mu infor­ma­tycz­ne­go» bez peł­ne­go zro­zu­mie­nia (czy­li tak­że udo­ku­men­to­wa­nia) «sys­te­mu informacyjnego»
2. nie ma żad­ne­go sen­su umiesz­cza­nie ele­men­tów «sys­te­mu infor­ma­tycz­ne­go» na mode­lach «sys­te­mu infor­ma­cyj­ne­go» (np. sym­bo­le repre­zen­tu­ją­ce opro­gra­mo­wa­nie na mode­lach BPMN)
3. związ­ki mię­dzy ele­men­ta­mi «sys­te­mu infor­ma­cyj­ne­go» i ele­men­ta­mi «sys­te­mu infor­ma­tycz­ne­go» opi­su­je­my z pomo­cą macie­rzy śladowania
4. opra­co­wa­nie wyma­gań na «sys­tem infor­ma­tycz­ny» pole­ga na ziden­ty­fi­ko­wa­niu «potrzeb biz­ne­so­wych» i opra­co­wa­niu na ich pod­sta­wie logi­ki dzia­ła­nia i archi­tek­tu­ry «sys­te­mu infor­ma­tycz­ne­go» (MBSE, MDD), a nie na zbie­ra­niu mitycz­nych ​„wyma­gań użyt­kow­ni­ków”, któ­rzy de fac­to nie mają poję­cia o ​„sys­te­mach infor­ma­tycz­nych», za to dosko­na­le wie­dzą czy i kie­dy potrze­bu­ją pomo­cy w reali­zo­wa­nych pro­ce­sach biznesowych
5. Poprawnie zapro­jek­to­wa­ne opro­gra­mo­wa­nie nie tyle ​„pozwa­la na prze­strze­ga­nie zasad”, co ​„nie pozwa­la na ich łama­nie”, dla­te­go wyso­kiej jako­ści opro­gra­mo­wa­nie jest pro­jek­to­wa­nie wg. zasad: pri­va­cy by design, law by design, rules by design.
6. Dlatego wła­śnie meto­dy opar­te na pro­jek­to­wa­niu «sys­te­mu infor­ma­tycz­ne­go» na bazie wywia­dów (warsz­ta­tów) z przy­szły­mi użyt­kow­ni­ka­mi są z góry ska­za­ne na nie­po­wo­dze­nie (bo nawet jak coś sen­sow­ne­go w koń­cu powsta­nie, to odbę­dzie się to ogrom­nych nakła­dem pra­cy meto­dą prób i błędów)

Jedno wie­my od lat: jed­ną z naj­bar­dziej szko­dli­wych tez w IT jest ta, mówią­ca, że doku­ment to raport z bazy danych. Po raz kolej­ny wyszło to z cała mocą w toku prac nad KSeF. Ciekawą i obszer­ną pra­ce na podob­ny temat opu­bli­ko­wał Danesi .

Dodatek: Wymagania na oprogramowanie

Czym są i jak okre­ślić wyma­ga­nia na opro­gra­mo­wa­nie? Popatrzmy na schemat:

Pracownicy orga­ni­za­cji, mając okre­ślo­ne umie­jęt­no­ści i upraw­nie­nia, prze­twa­rza­ją infor­ma­cje, któ­re są utrwa­la­ne w «sys­te­mie infor­ma­tycz­nym». Jak już wie­my, prze­twa­rza on dane. Wobec tego wyma­ga­niem na ten sys­tem jest opis: danych, reguł prze­twa­rza­nia oraz jego wewnętrz­na archi­tek­tu­ra. Może to być mono­lit jak więk­szość opro­gra­mo­wa­nia ERP na ryn­ku, a może to być sys­tem zbu­do­wa­ny z nie­za­leż­nych kom­po­nen­tów, tak by było moż­li­we jego czę­ścio­we wdra­ża­nie i mody­fi­ko­wa­nie. Dlatego opra­co­wa­nie wyma­gań wymaga:

1. ana­li­zy i mode­lu «sys­te­mu infor­ma­cyj­ne­go» w posta­ci mode­li pro­ce­sów biz­ne­so­wych (kto i co robi oraz kie­dy), jest to model CIM «sys­te­mu informacyjnego».
2. ana­li­za potrzeb (komu i jakie usłu­gi będzie świad­czył «sys­tem infor­ma­tycz­ny»), jest to model przy­pad­ków uży­cia «sys­te­mu informatycznego»,
3. mode­lu archi­tek­tu­ry «sys­te­mu infor­ma­tycz­ne­go» w dzie­dzi­nie prze­twa­rza­nia danych, jest to model PIM «sys­te­mu informatycznego».

Oznacza to tak­że, że do wyko­na­nia ana­li­zy «sys­te­mu infor­ma­cyj­ne­go» i zapro­jek­to­wa­nia «sys­te­mu infor­ma­tycz­ne­go», nie potrze­bu­je­my nicze­go poza dostę­pem do tych infor­ma­cji i danych, a to zna­czy, że ana­li­tyk-pro­jek­tant jest w sta­nie doko­nać tego w 100% zdal­nie. Wystarczy, że będzie umie­jęt­nie i meto­dycz­nie żądał mate­ria­łów źródłowych. 

Źrodła