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

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

Wprowadzenie

Ludzie i ich pra­ca to infor­ma­cje i ich wymia­na. Komputer i opro­gra­mo­wa­nie to mecha­nizm prze­twa­rza­nia danych repre­zen­tu­ją­cych te infor­ma­cje. Projektowanie opro­gra­mo­wa­nia pole­ga na zro­zu­mie­niu i opi­sa­niu tego mecha­ni­zmu, tego jakie to dane i jak są (ana­li­za) lub powin­ny być (pro­jek­to­wa­nie) prze­twa­rza­ne. Aby to zro­bić ana­li­zu­je­my doku­men­ty, nie robi­my wywiadów. 

Jeżeli ktoś tego nie potra­fi i nie rozu­mie, zaczy­na orga­ni­zo­wać wywia­dy i kodo­wać to, co ludzie postrze­ga­ją ze swo­jej per­spek­ty­wy. Tak powsta­je naj­gor­sze oprogramowanie. 

Można to zobra­zo­wać jak poniżej: 

Dlatego do opra­co­wa­nia pro­jek­tu przy­szłe­go «sys­te­mu infor­ma­tycz­ne­go» nale­ży naj­pierw zro­zu­mieć «sys­tem infor­ma­cyj­ny» fir­my (orga­ni­za­cji, bran­ży). W tym momen­cie możesz kon­ty­nu­ować lek­tu­rę tego wąt­ku w arty­ku­le System infor­ma­cyj­ny a infor­ma­tycz­ny.

Poniżej po lewej udo­ku­men­to­wa­ny efekt obser­wa­cji z Ziemi, opro­gra­mo­wa­nie powsta­ją­ce na bazie wywia­dów i obser­wa­cji ma potem podob­na struk­tu­rę. Po pra­wej stro­nie, efekt zro­zu­mie­nia obser­wa­cji: model, któ­re­go wyko­rzy­sta­nie do napi­sa­nia opro­gra­mo­wa­nia zaowo­cu­je opro­gra­mo­wa­niem o znacz­nie mniej­szej zło­żo­no­ści i jed­no­cze­śnie lep­sze, bo wier­niej odwzo­ro­wu­ją­ce sytu­ację biz­ne­so­wą”: powsta­nie szyb­ciej, będzie tań­sze w wytwo­rze­niu i w póź­niej­szym utrzy­ma­niu i rozwoju.

Analiza i modelowanie systemów
Analiza i mode­lo­wa­nie systemów

Dlatego napi­sa­łem też arty­kuł: User Story to wyma­ga­nie biz­ne­so­we, to opis pro­ble­mu do roz­wią­za­nia, a nie funk­cjo­nal­ność do imple­men­ta­cji! Poniżej po lewej opro­gra­mo­wa­nie, któ­re powsta­ło jako efekt imple­men­ta­cji kolej­nych wywia­dów z użyt­kow­ni­ka­mi (user sto­ry), po pra­wej efekt prze­my­śla­ne­go projektowania. 

źr.: User Story to wyma­ga­nie biz­ne­so­we, to opis pro­ble­mu do roz­wią­za­nia, a nie funk­cjo­nal­ność do implementacji!

Dalsza część arty­ku­łu to opis tego czym są meto­dy i teo­rie nauko­we. Czytelników, któ­rych meto­do­lo­gicz­ne deta­le nie inte­re­su­ją zachę­cam do lek­tu­ry wyżej cyto­wa­nych artykułów.

Twierdzenie naukowe

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

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

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

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

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

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

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

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

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

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

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

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

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

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

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

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

Dodatek

(dwa dni po publikacji)

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

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

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

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

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

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

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

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

Źródła

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

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Szympans u steru

    Amen.

    Ogólnie dostrze­gam ten­den­cję do uprasz­cza­nia wszyst­kie­go i wszę­dzie w okół nas. Dlatego mówie­nie o meto­dach nauko­wych” wią­że się z pew­nym ryzy­kiem ostra­cy­zmu z jakim moż­na się spotkać.

    Moja rada: Olać, robić swo­je naj­le­piej jak się da, nie prze­sa­dzać z nauko­wym słownictwem.


    Zresztą jeśli cho­dzi o uprosz­cze­nia to w tym jesteś dobry, widzia­łem kil­ka Twoich sche­ma­tów… mucha nie siada 🙂

    1. Jaroslaw Zelinski

      Co do ostra­cy­zmu owszem :). Co do robić swo­je naj­le­piej jak się da, nie prze­sa­dzać z nauko­wym słow­nic­twem” jak naj­bar­dziej, bo nale­ży dobie­rać meto­dy sto­sow­nie do pro­jek­tu, nie każ­dy nie­sie ze sobą na tyle wiel­kie ryzy­ko, by wyta­czać od razu naj­cięż­sze działa ;)…

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.