W strefie parkowania mandat się opłaca – czyli analiza systemowa … nie wykonana

Dziś trosz­kę ina­czej, w koń­cu na IT świat ana­li­zy sys­te­mo­wej się nie koń­czy. Na począ­tek cytat:

Od wtor­ku stre­fa płat­ne­go par­ko­wa­nia dzia­ła dłu­żej – od godz. 8 do 18. Dziesięciogodzinny postój kosz­tu­je 31,90 zł. Ale pani Monika, któ­ra pra­cu­je w oko­li­cach pl. Wolności, pła­ci 25,70 zł. – Do auto­ma­tu wrzu­cam mini­mal­ną kwo­tę, czy­li 70 gr, i zosta­wiam auto na cały dzień. Wiem, że dosta­nę 25 zł kary, któ­rą zapła­cę prze­le­wem – mówi. – To dla mnie wygod­niej­sze, bo zwy­kle nie mam w port­fe­lu tylu drob­nych, by wystar­czy­ło na 10 godzin posto­ju. A poza tym i tak jestem do przodu!

O tym, że stre­fa będzie dzia­łać dłu­żej, poznań­scy rad­ni zade­cy­do­wa­li 20 mar­ca. Ale nie prze­wi­dzie­li kre­atyw­no­ści” kie­row­ców. A ci obli­czy­li, że bar­dziej opła­ca im się łamać pra­wo, niż go prze­strze­gać. Jeśli więc zapła­cą za postój nie­peł­ną kwo­tę, dosta­ną 25-zło­to­wy man­dat. Jeśli nie wrzu­cą do auto­ma­tu nawet mini­mal­nej staw­ki, zapła­cą 35 zł kary. Dla porów­na­nia: za brak 2‑złotowego bile­tu w tram­wa­ju zapła­ci­my 100 zł.

- Kreatywność Polaków wciąż mnie zaska­ku­je. Ja bym na coś takie­go nie wpadł – przy­zna­je Tomasz Lewandowski, rad­ny SLD. – Ale rze­czy­wi­ście, kara nie może być niż­sza od opła­ty za stre­fę. Sprawdzimy, do jakiej wyso­ko­ści moż­na pod­nieść opła­tę dodat­ko­wą i zmie­ni­my to tak szyb­ko, jak to moż­li­we. (za W stre­fie par­ko­wa­nia man­dat się opła­ca).

Z przy­kro­ścią przy­zna­ję, że powyż­sza sytu­acja to efekt bra­ku kom­pe­ten­cji kon­struk­to­rów tego sys­te­mu opłat i kar. To, że Pan rad­ny Lewandowski nie wpadł by na to (zacho­wa­nia par­ku­ją­cych), wca­le go nie tłu­ma­czy, wręcz przeciwnie.

Przydaje się tak zwa­ne myśle­nie sys­te­mo­we. Cóż to jest? Niekoniecznie o sys­te­mach IT”. Elementem [[ogól­nej teo­rii sys­te­mów]] jest [[ana­li­za systemowa]]/1 (nazy­wa­na cza­sa­mi [[meto­dą nauko­wą ana­li­zy]]). Proces ana­li­zy sys­te­mo­wej to nastę­pu­ją­ce kroki:

  1. Formułowanie pro­ble­mu: opi­sa­nie ogra­ni­czeń, celów, kry­te­riów ich osiągnięcia.
  2. Wykrycie, selek­cja wariantów.
  3. Budowa mode­li i prze­wi­dy­wa­nie skutków.
  4. Porównanie skut­ków i sze­re­go­wa­nie wariantów.
  5. Analiza wyni­ków: rekomendacje.

W przy­pad­ku opłat za par­ko­wa­nie i kar, mamy typo­wy i bar­dzo pro­sty zara­zem pro­blem z teo­rii gier (tu model uży­ty do oce­ny warian­tów zacho­wa­nia i ich skut­ków). Uproszczone drze­wo takiej gry (opi­sa­no jedy­nie skraj­ne sytu­acje) ma pro­stą postać:

Gra toczy się pomię­dzy par­ku­ją­cy­mi a Miastem. Węzeł a to począ­tek gry, czy­li decy­zja o zapar­ko­wa­niu samo­cho­du. Parkujący może wyko­nać dwa ruchy (dwie decy­zje): pła­ci zgod­nie z regu­la­mi­nem (ten wariant ozna­cza tu zero­wą wygra­ną dla par­ku­ją­ce­go) lub wno­si mini­mal­ną opła­tę i pła­ci karę. Węzeł b poka­zu­je wypła­ty (zysk gra­cza vs. zysk mia­sta) w przy­pad­ku gdy par­ku­ją­cy zapła­ci zgod­nie z tary­fą. W takiej sytu­acji nic nie zysku­je (pła­ci tyle ile powi­nien) a mia­sto zysku­je 31,90 zł. Węzeł c poka­zu­je ruch gra­cza (par­ku­ją­cy ;)) pole­ga­ją­cy na wnie­sie­niu mini­mal­nej opła­ty i zapła­ce­niu kary, dają­cy mu wygra­ną 6,20 zł (tyle oszczę­dza). Jak nie trud­no się domy­śleć, par­ku­ją­cy na pew­no odkry­ją, że gra” ma dwie stra­te­gie, i że wybio­rą tę dają­cą im więk­szą wygra­ną. Gra ma masę warian­tów pośred­nich (róż­ne cza­sy par­ko­wa­nia), tu dla uprosz­cze­nia, opi­sa­no jed­nie dwa warian­ty skrajne.

Jak było by lepiej”? Kara powin­na nisz­czyć wygra­ną” par­ku­ją­ce­go tak więc powin­na wyno­sić co naj­mniej 31,20zł zamiast usta­lo­nej 25zł (mini­mal­na opła­ta plus kara powin­na być rów­na co naj­mniej opła­ci należ­nej). Z uwa­gi na to, że rolą kary jest nie tyl­ko nisz­czyć korzyść za łama­nia zasad ale tak­że odwo­dzić od ich łama­nia, powin­na być odczu­wal­nie (co by to tu nie mia­ło zna­czyć) wyż­sza. Nie będę się tu roz­wo­dził się nad tym, jaka powin­na być, inny jest cel arty­ku­łu (zain­te­re­so­wa­nym teo­rią gier pole­cam na począ­tek np. książ­kę [[Konkurencja i koope­ra­cja. Teoria gier w eko­no­mii i naukach spo­łecz­nych. Malawski, Wieczorek, Sosnowska]]).

Chce poka­zać, że pro­jek­to­wa­nie sys­te­mu opłat i kar powin­no być prze­pro­wa­dzo­ne pro­fe­sjo­nal­nie” a nie po ama­tor­sku. System powi­nien być tak zapro­jek­to­wa­ny by nie demo­ra­li­zo­wał i by był sku­tecz­ny. Radni będą, jak zade­kla­ro­wa­li, zmie­nia­li sys­tem kar. Ale nie­ste­ty ośmie­szy­li się w oczach oby­wa­te­li i stra­ci­li znacz­ne środ­ki (6,20 za każ­de źle opła­co­ne parkowanie).

Słowa brzyd­ko jest być nie­uczci­wym” pły­ną­ce z ust sta­no­wią­cych pra­wo, raczej roz­śmie­sza, bo to praw­da, że brzyd­ko, ale nie zmie­nia to fak­tu, że eko­no­mia jest bez­li­to­sna i na pew­no ludzie (wie­lu) znaj­dą wygry­wa­ją­cą” stra­te­gię, jeże­li tyl­ko taka ist­nie­je. Innymi sło­wy sko­ro mia­sto pobie­ra dwie róż­ne opła­ty za tę sama usłu­gę (z karą i bez), wybra­na zosta­je wer­sja o niż­szej opłacie.

Powyższe to namiast­ka zja­wi­ska psu­cia” pra­wa i nie­ste­ty demon­stro­wa­nia nie­kom­pe­ten­cji urzęd­ni­ków. Sam fakt, że tego nie prze­wi­dzie­li wysta­wia im sła­be świa­dec­two. A co dopie­ro w przy­pad­kach bar­dziej złożonych?

Urzędnicy, sko­ro już nie mają tych kom­pe­ten­cji, powin­ni uczyć się korzy­stać z pomo­cy spe­cja­li­stów. I nie tyl­ko urzędnicy…

/1 Analiza sys­te­mo­wa – to sztu­ka pozna­wa­nia i okre­śla­nia sys­te­mów dro­gą budo­wa­nia mode­li” ( J. Robertson, S. Robertson, Pełna ana­li­za sys­te­mo­wa, Wydawnictwo naukowo-techniczne)

Burza mózgów – homeopatia w analizie

Bardzo czę­sto moż­na spo­tkać w sie­ci i w lite­ra­tu­rze róż­ne podej­ścia do oce­ny skut­ków błę­dów ana­li­zy wyma­gań. Nie mniej wie­le jest spo­so­bów na odkry­wa­nie” wymagań.

Burza mózgów

Bardzo czę­sto spo­ty­kam się z roz­wle­kły­mi opi­sa­mi, wszel­kie­go rodza­ju ankie­ta­mi, wywia­da­mi, burza­mi mózgów, żół­ty­mi kar­tecz­ka­mi itp. Poradników nie bra­ku­je. Dyskusje na tego rodza­ju tema­ty doty­ka­ją zawsze pra­cy gru­po­wej i jej siły”. Niestety psy­cho­lo­gia daw­no dowio­dła, że np. dowol­na licz­ba stu­den­tów nie­po­tra­fią­ca zdać egza­mi­nu nie zda go pra­cu­jąc nad testem razem, i licz­ba tych stu­den­tów nie ma zna­cze­nia. Po pro­tu trze­ba mieć wie­dzę i umie­jęt­ność. (prze­czy­taj wię­cej o pra­cy gru­po­wej)

Można się czę­sto spo­tkać z tłu­ma­cze­niem tego, tak zwa­nym holi­stycz­nym podej­ściem mówią­cym, że całość zna­czy wię­cej niż suma skład­ni­ków. Zapewne tak jest ale to doty­czy raczej uzu­peł­nia­ją­cych się umie­jęt­no­ści: zarów­no spraw­ny fizycz­nie śle­piec jak i pozba­wio­ny nóg widzą­cy kale­ka, w poje­dyn­kę mają nikłe szan­se na samo­dziel­ne prze­ży­cie. Obaj razem mają znacz­nie więk­sze szan­se, sta­no­wią coś znacz­nie wię­cej niż niż każ­dy z nich z osob­na. Jednak jeśli żaden z nich nie potra­fi goto­wać, to razem tak­że nie potra­fią, nie będą potra­fi­li nawet jeśli takich jak oni (nie umie­ją­cych goto­wać) było by w tym zespo­le wię­cej. Burza mózgów tego zespo­łu nie da nic lep­sze­go do zje­dze­nia ponad to co potra­fi naj­lep­szy z nich (a jeże­li prze­pis usta­lą jako kom­pro­mis wła­snych pomy­słów, to chy­ba nie chciał bym tego jeść). A co na to nauka? Poniżej popu­lar­ny mit i efek­ty badań:

Tak więc porów­na­nie burzy mózgów z [[holizm]]em odbie­ram raczej jako nie­zro­zu­mie­niu tego drugiego.

Ciekawe jest to, że meto­da ta jest powszech­nie sto­so­wa­na” i zale­ca­na przez nie­jed­ną fir­mę dorad­czą (zary­zy­ku­ję, że przez więk­szość). Stosowana jest tak­że jako spo­sób na pro­blem” przez fir­my (zespo­ły), któ­re z jakie­goś powo­du, nie mają dostę­pu do potrzeb­ne­go spe­cja­li­sty (na temat tych powo­dów innym razem :))

Klasycznym przy­kła­dem opi­sa­ne­go podej­ścia są ana­li­zy i zbie­ra­nie wyma­gań wła­śnie meto­dą burzy mózgów, ankie­to­wa­nia przy­szłych użyt­kow­ni­ków, sesje JAD i podob­ne meto­dy. Skoro przy­szłe opro­gra­mo­wa­nie ma powstać na bazie wyma­gań (co by to nie mia­ło zna­czyć) to dla­cze­go auto­rzy pomy­słów na zbie­ra­nie wyma­gań meto­dą pra­cy gru­po­wej” nie posa­dzą tej gru­py od razu do napi­sa­nia tego opro­gra­mo­wa­nia? Zgodnie z ich podej­ściem gru­pa potra­fi wię­cej” wiec powin­no im się kie­dyś udać napi­sać dzia­ła­ją­cy pro­gram? Głupie? Nie! Próby są podej­mo­wa­ne, oto etap przejściowy:

Joint Application Development (JAD) ozna­cza współ­two­rze­nie apli­ka­cji. Jest to meto­dy­ka pole­ga­ją­ca na zaan­ga­żo­wa­niu klien­ta lub użyt­kow­ni­ka w pro­ces two­rze­nia opro­gra­mo­wa­nia, poprzez wpro­wa­dze­nie warsz­ta­tów współ­pro­jek­to­wa­nia, zwa­nych sesja­mi JAD. (źr. WIKI).

Prawdę mówiąc, obser­wu­jąc efek­ty tego podej­ścia, skła­niam się nie raz ku tezie, że JAD to prze­rzu­ce­nie znacz­nej czę­ści odpo­wie­dzial­no­ści za poten­cjal­ną poraż­kę na klien­ta: w koń­cu aktyw­nie brał Pan w tym udział wiec to nie tyl­ko nasza wina”. W moich oczach to raczej pró­ba w rodza­ju sko­ro nie umiem tego robić to może razem z klien­tem coś wymy­śli­my (zno­wu burza mózgów).

Proszę sobie kie­dyś w ramach ćwi­czeń poli­czyć kosz­ty sesji JAD (np. 15 osób na sali, kon­sul­tant pro­wa­dzą­cy i jego pomoc­nik notu­ją­cy, koszt opra­co­wa­nia danych z każ­dej sesji, razem raz w tygo­dniu przez rok trwa­nia pro­jek­tu). Drugie ćwi­cze­nie: ankie­ta wypeł­nio­na przez każ­de­go pra­cow­ni­ka szcze­bla śred­nie­go i wyżej. Najpierw czas tych ludzi jaki zaj­mu­je wypeł­nia­nie ankiet, potem koszt ich opra­co­wa­nia przez kon­sul­tan­tów w fir­my doradczej.

Pewna mię­dzy­na­ro­do­wa kor­po­ra­cja, chcąc oszczę­dzić na zatrud­nia­niu spe­cja­li­stów z zewnątrz, zarzą­dzi­ła by każ­dy ich zespół na świe­cie, meto­dą burzy mózgów, zapro­po­no­wał kil­ka spo­so­bów roz­wią­za­nia pew­ne­go pro­ble­mu. Z całe­go świa­ta napły­nę­ło ponad 6 tys. pomy­słów”, ich prze­twa­rza­nie tych danych trwa­ło pra­wie rok, by prze­ko­nać się, że w zasa­dzie pro­ble­mu nie roz­wią­za­no. Koszt cało­ści tej pra­cy (czas pra­cy wła­snych pra­cow­ni­ków odcią­gnię­tych od nor­mal­nych zajęć) wie­lo­krot­nie prze­wyż­szał war­tość odrzu­co­nych ofert ekspertów.

Ostatnio zro­bi­ła się moda na kon­kur­sy foto­gra­ficz­ne, kon­kur­sy na logo, kon­kur­sy na rekla­mę itp. dla ama­to­rów. Regulaminy więk­szo­ści z nich zawie­ra­ją zapi­sy o prze­ję­ciu praw mająt­ko­wych do nade­sła­nych prac. Często sły­szę, że zawo­do­wy foto­graf czy gra­fik chce za dużo” więc ogła­sza się kon­kurs z jakąś nagro­dą, uczest­ni­cy nade­ślą za dar­mo wie­le prac i coś się wybie­rze. Nie raz jed­nak koszt zor­ga­ni­zo­wa­nia, zbie­ra­nia i prze­glą­du prac, czas pra­cow­ni­ków zaan­ga­żo­wa­nych w cały ten pro­ces wie­lo­krot­nie prze­kra­cza to co sobie zaży­czył Pan foto­graf (czy grafik).

Agile

Niestety wie­le pro­jek­tów pro­gra­mi­stycz­nych to odkry­wa­nie wyma­gań w trak­cie” dostar­cza­nia pro­duk­tu. Po dostar­cze­niu jakie­goś frag­men­tu (lub nie raz pro­to­ty­pu cało­ści) bene­fi­cjent stwier­dza: to jest dokład­nie to cze­go chcie­li­śmy ale zupeł­nie nie to co jest nam potrzeb­ne”… Projekty z rodza­ju Agile WIKI defi­niu­je jako:

Programowanie zwin­ne ((ang.) Agile softwa­re deve­lop­ment) ? gru­pa meto­dyk wytwa­rza­nia opro­gra­mo­wa­nia opar­te­go na pro­gra­mo­wa­niu ite­ra­cyj­nym (model przy­ro­sto­wy). Wymagania oraz roz­wią­za­nia ewo­lu­ują przy współ­pra­cy samo­za­rzą­dzal­nych zespo­łów, któ­rych celem jest prze­pro­wa­dza­nie pro­ce­sów wytwa­rza­nia opro­gra­mo­wa­nia (źr. WIKI)

Nie jestem wro­giem Agile jako zwin­no­ści, gdyż sam uwa­żam, że nale­ży się dosto­so­wy­wać, ale zwin­ność postrze­gam raczej jako dosto­so­wa­nie metod pra­cy a nie brak pla­no­wa­nia i pro­jek­to­wa­nia (przy­po­mi­nam, że pla­no­wa­nie nie pole­ga na usta­le­niu pla­nu cyklicz­nych spo­tkań a na usta­le­niu co kie­dy powstanie).

Niestety bar­dzo czę­sto pro­jek­ty Agile przy­po­mi­na­ją powyż­szy rysu­nek z mostem (napis na rysun­ku brzmi: może jed­nak zbu­duj­my łódź zamiast tego?) bo w Agile roz­wią­za­nia ewo­lu­ują”. W efek­cie na począt­ku pro­jek­tu nie wie­my co i jakim kosz­tem powsta­nie… o ile w ogó­le powsta­nie, bo może skoń­czyć się finansowanie.

Na zakończenie

Burze mózgów mają sens, jak naj­bar­dziej, ale w przy­pad­ku zespo­łu spe­cja­li­stów. Jeżeli zacho­dzi ryzy­ko, że jeden spe­cja­li­sta w danej dzie­dzi­nie, będzie pra­co­wał nad uzy­ska­niem roz­wią­za­nia zbyt dłu­go na co nie ma cza­su, zamiast jed­ne­go spe­cja­li­sty sadza­my” kil­ku (słyn­na sce­na w Apollo 13). Jest bar­dzo praw­do­po­dob­ne, że któ­ryś z nich wpad­nie na wła­ści­wy pomysł szyb­kiej niż kole­dzy. Jest nawet meto­da pole­ga­ją­ca na uzu­peł­nia­niu takie­go zespo­łu oso­bą z innej dzie­dzi­ny w celu wpro­wa­dze­niu ele­men­tu nie­sza­blo­no­we­go myśle­nia” (nie ma głu­pich pomy­słów, są tyl­ko w danym przy­pad­ku nie przy­dat­ne). Ale efekt (pomy­słu laika”) i tak będzie wyma­gał wie­dzy spe­cja­li­stów by go wdrożyć.

Jak spe­cy­fi­ko­wać wyma­ga­nia? Cały ten blog trak­tu­je o tym jak, w spo­sób usys­te­ma­ty­zo­wa­ny i nie­ste­ty” trosz­kę nauko­wy. Można to zro­bić, opra­co­wać wyma­ga­nia na opro­gra­mo­wa­nie, dobrze oraz rela­tyw­nie tanio i sku­tecz­nie (ana­li­tyk w zasa­dzie zawsze jest tań­szy niż koszt burza mózgów: jej człon­ko­wie i opra­co­wa­nie wyni­ków). Na jed­nym z forów w toku dys­ku­sji na podob­ny temat napisałem:

… czym innym jest kom­pli­ka­cja [pra­co­chłon­ność] a czym innym trud­ność (umie­jęt­ność zro­bie­nia cze­goś), np. robie­nie dobrych zdjęć nie jest skom­pli­ko­wa­ne (np. jeden guzik w tele­fo­nie) ale jest trud­ne (trud­no jest zro­bić zdję­cie, któ­re zachwy­ci foto­edy­to­ra gaze­ty) zaś ich wywo­ły­wa­nie nie jest trud­ne ale jest skom­pli­ko­wa­ne… dla­te­go dla ludzi, któ­rzy nie rozu­mie­ją swo­jej pra­cy (bo nie zawsze muszą i nie zawsze jest takie ocze­ki­wa­nie) two­rzy się pro­ce­du­ry np. instruk­cja obsłu­gi foto­la­bu eks­pre­so­we­go. Podobnie pro­jek­to­wa­nie: ono nie jest skom­pli­ko­wa­ne ale jest trud­ne, ani pro­ce­du­ry ani licz­ba osób nie przy­bli­żą nas do lep­sze­go projektu…

Jeśli coś jest skom­pli­ko­wa­ne, zło­żo­ne, moż­li­wym roz­wią­za­niem jest doda­nie zaso­bów i wła­ści­wych pro­ce­dur. Jednak jeśli coś jest trud­ne, potrzeb­ny jest po pro­tu ktoś, kto potrafi.

Czemu o tym piszę? A bo wła­śnie mam przed sobą kolej­ny doku­ment o nazwie SIWZ, wyko­na­ny tech­ni­ką burzy mózgów i ankie­to­wa­nia (w obsza­rze spe­cy­fi­ka­cja wyma­gań), jakimś kosz­tem (czas pra­cow­ni­ków albo koszt kon­sul­tan­ta pra­cu­ją­ce­go tą wła­śnie meto­dą) opra­co­wa­no tę spe­cy­fi­ka­cję wyma­gań a teraz zama­wia­ją­cy sam przy­zna­je (po roz­strzy­gnię­ciu prze­tar­gu), że ana­li­za wyma­gań (teraz) jest potrzeb­na bo ów SIWZ jest nie­spój­ny, ma bra­ki i wyma­ga korek­ty i uzu­peł­nień”. Z tego powo­du tak­że nie ma pew­no­ści, że w ogó­le dobrze opi­sa­no Przedmiot Zamówienia!.

Metoda naukowa w analizie biznesowej

Struktura analizy

Dokumenty, któ­re two­rzę, maja struk­tu­rę typo­wej pra­cy nauko­wej, czy­li skła­da­ją się z nastę­pu­ją­cych części:

  • Wprowadzenie: jak wyglą­da sytu­acja, co jest pro­ble­mem do roz­wią­za­nia (np. w danej orga­ni­za­cji), jak go stwier­dzo­no, jakie fak­ty świad­czą o tym, jaki jest cel.
  • Opis uży­tych metod.
  • Opis dzia­ła­nia bada­nej orga­ni­za­cji, rekomendacje.
  • Opis reko­men­do­wa­ne­go roz­wią­za­nia: pro­jekt zmian orga­ni­za­cyj­nych, opis (pro­jekt) reko­men­do­wa­ne­go opro­gra­mo­wa­nia, itp.
  • Opis dal­szych prac i podsumowanie.
  • Rejestr wszel­kich wyja­śnień udzie­lo­nych w kwe­stii tre­ści doku­men­tu i jego rozszerzeń. 

Zainteresowanych szcze­gó­ła­mi zapra­szam do dal­szej lek­tu­ry tego artykułu.

Krótko o metodzie naukowej

Dużo piszę na blo­gu o ana­li­zie wyma­gań opar­tej na mode­lach i ana­li­zie sys­te­mo­wej, jako pod­sta­wie meto­dy­ki pro­wa­dze­nia ana­liz. Są to ogól­nie tak zwa­ne meto­dy nauko­we . Cechy tego podejścia:

Idealny, prak­tycz­ny model meto­dy naukowej 

Tradycyjnie, nie­za­leż­nie od roz­ma­itych kwe­stii filo­zo­ficz­nych i spo­łecz­nych, zazwy­czaj przyj­mu­je się, że na meto­dę nauko­wą skła­da się nastę­pu­ją­cy zbiór czyn­no­ści ?*?:

  • Obserwacje wstęp­ne
  • Budowanie hipo­te­zy
  • Wykonywanie rze­tel­nych eks­pe­ry­men­tów wery­fi­ku­ją­cych hipo­te­zę lub rze­tel­ne zbie­ra­nie danych histo­rycz­nych mają­cych potwier­dzić teo­rię lub jej zaprzeczyć
  • Przyjęcie lub odrzu­ce­nie hipo­te­zy w opar­ciu o zebra­ne dane.
  • Powtarzanie pro­ce­du­ry – czy­li sta­ła wery­fi­ka­cja sta­rych i budo­wa­nie nowych hipo­tez w momen­cie gdy sta­re prze­sta­ją się sprawdzać.

Ponadto, wyni­ki badań nauko­wych pod­da­ne muszą być kry­ty­ce innych naukowców.

Jednym z pod­sta­wo­wych narzę­dzi metod nauko­wych, jest tak zwa­na idealizacja:

Idealizacyjna Koncepcja Nauki
Punktem wyj­ścia ide­ali­za­cyj­nej kon­cep­cji nauki było spo­strze­że­nie (1968, ss.80n., 1970a, 1971a […]), że wbrew induk­cjo­ni­zmo­wi, nauki empi­rycz­ne nie uogól­nia­ją fak­tów empi­rycz­nych w pra­wa ? pra­wa mówią o gazach (ryn­kach, pra­wo­daw­cach, itd.) dosko­na­łych a fak­ty noto­rycz­nie wyda­rza­ją się gazom (ryn­kom, pra­wo­daw­com, itd.) dale­kim od dosko­na­ło­ści, bo ?real­nie ist­nie­ją­cym?. .

Idealizacja pole­ga roz­po­czy­na­niu wyja­śnia­nia doko­na­nych obser­wa­cji z uży­ciem mini­mal­ne­go mode­lu. Model tej jest testo­wa­ny kolej­ny­mi fak­ta­mi i roz­sze­rza­ny jest o ile wyma­ga tego wyja­śnie­nie kolej­nych fak­tów. Po kil­ku takich ite­ra­cjach model pod­da­wa­ny jest kry­ty­ce innych obser­wa­to­rów, może być dalej popra­wia­ny lub uzna­ny za popraw­ny (nie­pod­wa­żo­ny). Na tym eta­pie uzna­je­my, że tak powsta­ły model wyja­śnia obser­wo­wa­ne fak­ty: jest nauko­wą teo­rią wyja­śnia­ją­cą (meto­do­lo­gia nauk). Idealizacja, jako narzę­dzie, zna­la­zła tak­że zasto­so­wa­nie na polu ana­liz biz­ne­so­wych .

A co na naszym analitycznym podwórku?

Pojęcie model poja­wia się w pro­jek­tach ana­li­tycz­nych nie­mal­że w 100% przy­pad­ków. Potocznie mówi się, że powsta­ją mode­le pro­ce­sów biz­ne­so­wych, mode­le przy­pad­ków uży­cia, mode­le dzie­dzi­ny sys­te­mu i wie­le innych. Warto jed­nak wie­dzieć, że co praw­da mode­lem bywa nawet poje­dyn­czy dia­gram (sche­mat blo­ko­wy), jed­nak jeże­li mówi­my o mode­lu dzia­ła­nia jakiejś orga­ni­za­cji (urząd, przed­się­bior­stwo, inne) to jest on raczej bar­dziej zło­żo­ny i przed­sta­wia­ny jest na wie­lu róż­nych dia­gra­mach. Często sto­so­wa­ne jest poję­cie per­spek­ty­wy mode­lo­wa­nia, co zna­czy, że two­rzy­my kon­tek­sto­wy opis dzia­ła­nia. Tak kon­tra­sto­wość pole­ga na pomi­ja­niu jed­nych aspek­tów mecha­ni­zmu dzia­ła­nia orga­ni­za­cji na korzyść innych.

Jeżeli opi­su­je­my orga­ni­za­cję z per­spek­ty­wy kolej­no­ści reali­zo­wa­nych zadań i ich pro­duk­tów abs­tra­hu­jąc cał­ko­wi­cie od tego jakich narzę­dzi uży­wa­ją wyko­naw­cy tych czyn­no­ści, two­rzy­my model pro­ce­sów biz­ne­so­wych. Model taki poka­zu­je jakie zada­nia, i w jakim celu, są reali­zo­wa­ne. Z tego powo­du jest uzu­peł­nia­ny mode­lem reguł biz­ne­so­wych (logi­ka reali­za­cji pro­ce­sów) i mode­lem poję­cio­wym (jed­no­znacz­ność), tłu­ma­czą­cym zna­cze­nia pojęć uży­tych w tych mode­lach. Skoro są ludzie i uży­wa­ją narzę­dzi do pra­cy, poja­wia się tak­że potrze­ba opi­sa­nia tych narzę­dzi. Powodem jest zro­zu­mie­nie tego jak dzia­ła­ją i jak poma­ga­ją ludziom w reali­za­cji ich zadań, część z nich słu­ży do auto­ma­ty­zo­wa­nia pew­nych prac. Jednym z takich narzę­dzi jest opro­gra­mo­wa­nie (apli­ka­cja) a ich opis to albo doku­men­ta­cja apli­ka­cji ist­nie­ją­cej, albo pro­jekt pla­no­wa­nej do wyko­na­nia i dostarczenia. 

Tu poja­wia się zada­nie: zro­zu­mieć jak dzia­ła orga­ni­za­cja i zapro­jek­to­wać narzę­dzie, któ­re będzie poma­ga­ło w zada­niach jakie ona reali­zu­je. Rzecz w tym, że opro­gra­mo­wa­nie jako narzę­dzie nie jest zama­wia­ne jako coś cze­go wyma­ga orga­ni­za­cja” a jako coś co wes­prze jej dzia­ła­nie”, narzę­dzie sta­no­wią­ce roz­wią­za­nie” pro­ble­mu jaki chce roz­wią­zać zamawiający.

Gdzie tu miej­sce na nauko­we meto­dy? Mamy dwa zada­nia do wykonania:

  1. opra­co­wać model dzia­ła­nia orga­ni­za­cji czy­li opra­co­wać teo­rią wyja­śnia­ją­cą to, co się w niej dzieje,
  2. opra­co­wać pro­jekt roz­wią­za­nia czy­li zbu­do­wać mecha­nizm dzia­ła­nia narzę­dzia, któ­re umiesz­czo­ne w tej orga­ni­za­cji, roz­wią­że pro­blem opi­sa­ny przez zama­wia­ją­ce­go; to narzę­dzie może być zre­ali­zo­wa­ne jako oprogramowanie.

Potocznie pierw­szy etap nazy­wa­ny jest Analizą biz­ne­so­wą dru­gi to Projektowanie logi­ki opro­gra­mo­wa­nia. Przyjmując, że sto­su­je­my nauko­we podej­ście, naj­pierw two­rzy­my model orga­ni­za­cji a potem model logi­ki potrzeb­ne­go jej opro­gra­mo­wa­nia (teo­rie mówią­ce, że tak to dzia­ła), testu­je­my je i uzna­je­my za popraw­ne, jeże­li nie uda­ło ich pod­wa­żyć. Na tym blo­gu znaj­dzie opis takie­go pro­ce­su pod nazwą MDA. Jednak jeże­li nauko­wo to opie­ra­my się wyłącz­nie na fak­tach (czy­li nie pro­wa­dzi­my wywia­dów a ana­li­zu­je­my dokumenty).

Po kolei:

  • obser­wa­cje to ana­li­za tego co i jak się w fir­mie dzie­je (ana­li­za fak­tów czy­li doku­men­tów, wywia­dy tyl­ko w ostateczności),
  • budo­wa­nie hipo­te­zy to two­rze­nie mode­lu logi­ki dzia­ła­nia (pro­ce­so­we­go, obiek­to­we­go) tej firmy,
  • eks­pe­ry­men­ty to testo­wa­nie mode­li poprzez spraw­dza­nie czy są jakieś fak­ty w orga­ni­za­cji, któ­rych nie potra­fi­my wyja­śnić naszym modelem,
  • przy­ję­cie lub odrzu­ce­nie i napra­wa” hipo­te­zy czy­li ulep­sza­nie mode­lu (jeśli był wadliwy).

Moje pro­jek­ty to nic inne­go jak kon­kret­ne powsta­łe spe­cy­fi­ka­cje wyma­gań na opro­gra­mo­wa­nie sta­no­wią­ce sobą tak na praw­dę mode­le mecha­ni­zmu dzia­ła­nia. Spełnienie wyma­gań to zgod­ność zacho­wa­nia opro­gra­mo­wa­nia z opi­sa­nym (wyma­ga­nym) mecha­ni­zmem, zgod­ność tę spraw­dza­my testa­mi.

Na koniec o tym czym jest hipoteza:

Hipoteza – osąd, teo­ria, któ­ra nie zna­la­zła jesz­cze potwier­dze­nia w fak­tach, lub w przy­pad­ku hipo­tez mate­ma­tycz­nych nie zosta­ła jesz­cze popraw­nie udo­wod­nio­na.
Stawianie i testo­wa­nie hipo­tez to jeden z pod­sta­wo­wych pro­ce­sów twór­cze­go myśle­nia oraz fun­da­men­tal­ny ele­ment pro­ce­su two­rze­nia nauki.

(źr. cyta­tów Metoda nauko­wa).

Tak więc, sko­ro opro­gra­mo­wa­nie w swej cen­tral­nej czę­ści zawie­ra Model (patrz wzo­rzec MVC) logi­ki biz­ne­so­wej, to zna­czy, że nale­ży naj­pierw (1) zro­zu­mieć jak dzia­ła ta orga­ni­za­cja i udo­ku­men­to­wać jej model dzia­ła­nia, (2) pod­jąć decy­zję któ­ry obszar dzia­ła­nia orga­ni­za­cji ma być wspie­ra­ny nowym opro­gra­mo­wa­niem, i któ­ra część jej mode­lu dzia­ła­nia ma być zaim­ple­men­to­wa­na w opro­gra­mo­wa­niu, (3) wyko­nać implementację.

User Story to co naj­wy­żej mate­riał badaw­czy a Przypadki uży­cia to zakres pro­jek­tu. Kluczem jest zro­zu­mie­nie mecha­ni­zmu dzia­ła­nia, tak jak pra­wa fizy­ki są tym co tłu­ma­czy dzia­ła­nie nawet pro­ste­go młotka…

Jeżeli ktoś uwa­ża, że zapis z obser­wa­cji zacho­wa­nia się orga­ni­za­cji może sta­no­wić wyma­ga­nie dla inży­nie­ra, to tak jak by uznał, że zapis obser­wa­cji zacho­wa­nia się samo­cho­du i jego kie­row­cy może sta­no­wić wystar­cza­ją­cy mate­riał do wypro­du­ko­wa­nia skrzy­ni biegów… 

Teorie, któ­re nie mogą być prze­te­sto­wa­ne, bo np. to co opi­su­ją nie jest obser­wo­wal­ne, nie kwa­li­fi­ku­ją się jako teo­rie
nauko­we. Przykłady:

Księżyc zasie­dla­ją Małe Zielone, któ­rych ani
nie moż­na zoba­czyć, ani zła­pać ? ŹLE

Na Księżycu nie ma Małych Zielonych ?
DOBRZE, łapiąc jed­ne­go moż­na sfal­sy­fi­ko­wać
hipo­te­zę

Polecam tak­że źró­dło­wy wykład: meto­da nauko­wa.

(źr. http://www.home.umk.pl/~mwojc/wyklady_Teren/metoda%20naukowa.pdf)


  1. ?*?
    patrz tak­że http://​www​.racjo​na​li​sta​.pl/​k​k​.​p​h​p​/​s​,​2​432

Żródła

McMullin, E. (1985). Galilean ide­ali­za­tion. Studies in History and Philosophy of Science Part A, 16(3), 247 – 273. https://​doi​.org/​1​0​.​1​0​1​6​/​0​039 – 3681(85)90003 – 2
Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: cre­ating an organization’s futu­re. Wharton School Pub.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Subbotin A.L. (1970). Idealization as a Method of Scientific Knowledge. In Tavanec P.V. (eds) Problems of the Logic of Scientific Knowledge. Synthese Library.
Wheeler, B. (2018). Idealization and the Laws of Nature. Springer.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
Nola, I. R., & Sankey, H. (n.d.). HARD PROBLEMS IN THE PHILOSOPHY OF SCIENCE: IDEALIZATION AND COMMENSURABILITY. 20.

Aktualizacja gru 21, 2020 @ 23:25

Czego moglibyśmy się nauczyć od naukowców?

Nie jest tu, na moim blo­gu, tajem­ni­cą, że pre­fe­ru­ję nauko­we meto­dy ana­li­zy. Nie cho­dzi o gma­twa­nie świa­ta” a o pro­ste a sku­tecz­ne podej­ście. Codzienna lek­tu­ra blo­gów zapro­wa­dzi­ła mnie dziś na stro­ny pro­gra­mi­sty, któ­ry napisał:

Czego mogli­by­śmy się nauczyć od naukow­ców? A być może tego jak waż­ną rolę i jak bar­dzo cza­so- i kosz­to­chłon­ne jest samo pla­no­wa­nie eks­pe­ry­men­tu, jak waż­ne jest zro­zu­mie­nie czyn­ni­ków zewnętrz­nych któ­re mogą mieć wpływ na prze­bieg eks­pe­ry­men­tu. Być może war­to się zanu­rzyć w ten świat i spróbować.

Zapowiada się nie­źle. oso­bi­ście uwa­żam, że eks­pe­ry­ment jest gene­ral­nie tań­szy i bez­piecz­niej­szy od ćwi­czeń na żywym cie­le, te ostat­nie są zresz­tą nie raz wręcz zabro­nio­ne. Zanurzanie się w świat rze­czy­wi­sty” wiec nie raz jest moż­li­we tyl­ko raz: odda­ją goto­we roz­wią­za­nie (w zasa­dzie jak samo­lot, goto­wy jest obla­ty­wa­ny już z czło­wie­kiem na pokładzie).

Bardzo podo­ba mi się oso­bi­ście idea eks­pe­ry­men­tu. W moim, tak uwiel­bia­nym wąt­ku archi­tek­tu­ry, ana­li­zy biz­ne­so­wej i zarzą­dza­nia pro­jek­ta­mi cza­sa­mi zbyt czę­sto zawie­rza­my teo­riom, mani­fe­stom, wzo­rom i skom­pli­ko­wa­nym mecha­ni­zmom wyli­cza­nia popraw­no­ści zło­żo­no­ści wszech­świa­ta. Naukowcy w sytu­acji gdy zło­żo­ność pro­ble­mu unie­moż­li­wia jego roz­wią­za­nia meto­da­mi ana­li­tycz­ny­mi zwra­ca­ją się ku eks­pe­ry­men­to­wi”. Dlatego bła­gam was archi­tek­ci i ana­li­ty­cy, następ­nym razem gdy będzie­cie pró­bo­wa­li zapro­jek­to­wać zło­żo­ny sys­tem wyko­rzy­staj­cie siłę jaką daje eks­pe­ry­ment. Wszelkiej maści pro­to­ty­py”, testy” czy też Agile’owe spi­ke” są lep­sze niż UML’e, dia­gra­my, work­flo­w’y i rysu­necz­ki z pro­ce­sa­mi biz­ne­so­wy­mi. Programiści was polu­bią za cie­ka­we zada­nia, a wy będzie­cie się mogli pochwa­lić dzia­ła­ją­cy­mi systemami.

I tu zaczy­na­ją się scho­dy. Bo jeże­li rozu­miem pro­gra­mi­stów, że lubią się bawić na koszt klien­ta, to nie rozu­miem dla­cze­go od razu chcą latać na pro­to­ty­pach samo­lo­tów, gorzej, nie chcą cze­kać na pro­jekt i te śmiesz­ne rysun­ki tech­nicz­ne. Dlaczego inży­nier mecha­nik chce zaj­mo­wać się pro­jek­to­wa­niem tego jak ma wyglą­dać i latać samo­lot sko­ro jego rola i kom­pe­ten­cje to kon­stru­owa­nie a nie np. bada­nie satys­fak­cji klien­ta z lotu na wygod­nym fotelu…

Jak mam sobie wyobra­zić two­rze­nie samo­lo­tu w posta­ci pod­sta­wia­nych na lot­ni­sko pasa­żer­skie kolej­nych pro­to­ty­pów? Czy każ­dy pro­jekt IT to samo­lo­ty? Tak! Tam pra­cu­ją ludzie, pła­cą za to i cier­pi ich biz­nes jak opro­gra­mo­wa­nie nie zadzia­ła od razu jak trzeba!

Czy pro­to­ty­py kodu są lep­sze o niż mode­le pro­ce­sów i pro­jek­tu UML? Ja zapy­tam: opra­co­wa­nie i prze­te­sto­wa­nie mapy pro­ste­go pro­ce­su, potem przy­pad­ku uży­cia, kawał­ka mode­lu dzie­dzi­ny i testo­wa­nie tego dia­gra­mem sekwen­cji to pra­ca dla mnie, jed­nej oso­by, na kart­ce papie­ru, koszt to jakieś np. 1000zł. Oddaje pro­dukt (pro­jekt) nie wyma­ga­ją­cy nicze­go poza imple­men­ta­cją. Czy za 1000zł ktoś posa­dzi czło­wie­ka lub ludzi, napi­sze i prze­te­stu­je kod kil­ku­na­stu klas plus dzie­siąt­ków tech­nicz­nych, mając do dys­po­zy­cji jakąś plat­for­mę by to uru­cho­mić? I klient odbie­rze i uży­je to za pierw­szym razem?

Naukowe meto­dy, szcze­gól­nie te zda­rze­nio­we, pole­ga­ją­ce na sta­wia­niu tezy i pró­bie jej fal­sy­fi­ka­cji, to po pierw­sze sku­tecz­ne meto­dy, po dru­gie nie­in­wa­zyj­ne, po trze­cie rela­tyw­nie tanie (w rela­cji do pra­cy na żywym ciele/kodzie). Po co work­flow? Po to by prze­te­sto­wać, czy to co opo­wia­da nie­udol­nie i mozol­nie klient jest logicz­ne, jest praw­dą (tak!). Przetestowany pro­ces biz­ne­so­wy to nic inne­go jak makie­ta, dobry plan mia­sta do pla­no­wa­nia wyciecz­ki. UML? Cóż, moż­na wpu­ścić tabun mura­rzy na budo­wę bez pro­jek­tu archi­tek­to­nicz­ne­go, i meto­dą pro­to­ty­py”, testy” czy też Agile’owe spi­ke” posta­wią wie­żo­wiec ale nie jestem pewien czy to będzie tanio i nie wiem czy odwa­żył bym bym się w tym czymś zamiesz­kać. Po dru­gie zapy­tam: sko­ro te UML’e głu­pie to dla­cze­go książ­ki o wzor­cach pro­jek­to­wych i archi­tek­tu­rze sys­te­mów są nimi nafaszerowane?

Czego jesz­cze może­my się nauczyć od naukow­ców? A to że Dobry eks­pe­ry­ment musi być jak naj­prost­szy w wyko­na­niu i jed­no­cze­śnie dawać jak naj­bar­dziej jed­no­znacz­ną odpo­wiedź potwier­dza­ją­cą lub fal­sy­fi­ku­ją­cą daną teo­rię” (Wikipedia). Czyli Keep Your Tests Simple. (źr. cyta­tów: pri​mi​ti​ve​.jog​ger​.pl.)

A tu pro­szę, same roz­sąd­ne rze­czy (może dla­te­go że prze­pi­sa­ne z WIKI). Oczywiście: model pro­ce­su dobry, to pro­sty model, jego testo­wa­nie tak­że nie jest skom­pli­ko­wa­ne, a odpo­wiedź zero­je­dyn­ko­wa: dzia­ła albo nie działa.

Autor pisze na poczat­ku swo­je­go arty­ku­łu, że stwo­rze­nie pro­gra­mu to teza:

  1. przy zało­żo­nym cza­sie (t) oraz zało­żo­nym budże­cie (b) dostar­czy­my sys­tem (S)
  2. któ­ry dane wej­ścio­we (i) prze­kształ­ci w dane wyj­ścio­we (o)

Haczyk tu tkwi, w tym, że więk­szość pro­gra­mi­stów rzu­ca się na takie coś mimo, że nie dys­po­nu­je opi­sem czym jest (S). Bo nie są nim ani przy­pad­ki uży­cia ani user sto­ry anie notat­ki z sesji JAD. Po dru­gie czym jest ten­że sys­tem”? Bez jego pro­jek­tu nie da się okre­ślić ani ter­mi­nu ani budże­tu ani cza­su wyko­na­nia. To tak jak by ktoś napi­sał, że przy zało­żo­nym cza­sie i budże­cie zbu­du­je hotel wie­dząc jedy­nie ilu gości będzie musiał przy­jąć w cią­gu doby”.

Podejrzewam, że autor po pro­stu miał tego pecha, że dosta­wał jakieś kiep­skie ana­li­zy i pro­jek­ty, beł­kot, któ­re­go nie­ste­ty jest masa. Wtedy jak naj­bar­dziej ma pra­wo mieć rację (tro­chę). ale co dalej znaj­du­je­my na tym blogu:

Estymaty pro­jek­tów przy zasto­so­wa­niu zasa­dy 200% bufo­ru bez­pie­czeń­stwa nadal roz­pa­da­ją się jak zam­ki z pia­sku. Jak to kole­ga ujął pró­bu­jąc zamknąć defi­ni­cję Agile w jed­nym zda­niu klient nadal nie wie co chce, a my dostar­czy­my co mamy” (źr. Slow coding).

Proponuje mu albo jego kie­row­ni­kom pro­jek­tów (w sumie to nie wiem kogo tu oce­niać…) więc poczytać:

  1. opis ana­li­zy meto­dą nauko­wą: Analiza sys­te­mo­wa – ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie systemów
  2. oraz IIBA czy­li jak to robią…

oraz: książ­ki Fowlera, Yourdona, Evansa czy tak zwa­ne­go Gangu Czworga.

Nie są to może jakieś wypa­sio­ne pro­jek­ty ale co do zasa­dy są to owe work­flow­ły i jueme­le do zapo­zna­nia się…:

Na zakończenie

Co mogę po tym powie­dzieć? Państwo sami zde­cy­duj­cie co woli­cie w swo­ich pro­jek­tach: 200% narzu­tu na swo­bod­ne podej­ście dostaw­ców opro­ga­ra­mo­wa­nia czy 20% na dobre­go ana­li­ty­ka pro­jek­tan­ta i dru­gie 20% jakie uczci­wy dostaw­ca doda mając dobry projekt …

Autor napi­sał swo­ją odpo­wiedź i dobrze, bo pole­mi­ka kształci:

http://​pri​mi​ti​ve​.jog​ger​.pl/​2​0​1​1​/​0​5​/​2​3​/​p​o​r​z​a​d​n​i​e​-​m​i​-​s​i​e​-​o​b​e​r​w​a​lo/

Autor napi­sał: Po dogłęb­nym zapo­zna­niu się z pra­ca­mi auto­ra dzie­lę się moimi prze­my­śle­nia­mi i cze­kam na rów­nie cię­tą ripo­stę „, któ­rą napi­sa­łem i nie­zbyt cię­tą (nie to było celem) szko­da jed­nak, że ten­że autor nie tyl­ko sto­su­je tanie ery­stycz­ne chwy­ty w swo­ich wypo­wie­dziach (np. przy­rów­ny­wa­nie praw­dzi­wo­ści swo­ich tez do pew­no­ści odkry­cia Kopernika: posta­no­wi­łem trwać przy mej teo­rii iż to jed­nak Ziemia krą­ży wokół Słońca” co jest dość duża zaro­zu­mia­ło­ścią, bo jeśli w kwe­stii ukła­du sło­necz­ne­go fak­tycz­nie nie mamy wąt­pli­wo­ści to moż­na je mieć w kwe­stii wywo­dów tegoż auto­ra), a w koń­cu usu­nął ze swo­jej stro­ny (dla­cze­go?) po pew­nym cza­sie moją krót­ką odpo­wiedź i link do jej peł­nej wer­sji na tym blogu:

https://it-consulting.pl//index.php/2011/05/24/polemika/

analiza systemowa oraz modelowanie jako jej główne narzędzie.

Analiza Systemowa – analiza biznesowa i projektowanie systemów

W stycz­niu tego (2011) roku napi­sa­łem: Mamy więc ana­li­zę biz­ne­so­wą i spe­cy­fi­ko­wa­nie wyma­gań poprzez opra­co­wa­nie wery­fi­ko­wal­nych mode­li a nie tyl­ko listę potrzeb, któ­rej nie­ste­ty nie da się zwe­ry­fi­ko­wać co do kom­plet­no­ści i spój­no­ści bo nie ma narzę­dzia spraw­dza­ją­ce­go. Co jest takim narzę­dziem? Ano mode­le i to, że powsta­ły (jeże­li powsta­ły) przy pomo­cy sfor­ma­li­zo­wa­nej nota­cji. (źr. Analiza przed­wdro­że­nio­wa ? czym jest | Jarosław Żeliński – rynek IT, ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie sys­te­mów).

Przyszła pora na opi­sa­nie samej ana­li­zy. Skoro więc ana­li­za bazu­je na mode­lach, naj­czę­ściej dia­gra­mach, poku­si­łem się na, tym razem na nie­for­mal­ny dia­gram obra­zu­ją­cy ana­li­zę sys­te­mo­wą w kon­tek­ście inży­nie­rii oprogramowania.

Mamy dwa ele­men­ty tej ana­li­zy: ana­li­zę sys­te­mo­wą jako pro­ces głów­ny oraz mode­le jako narzę­dzia testo­wa­nia hipo­tez. W przy­pad­ku pro­jek­to­wa­nia celem jest pro­jekt rozwiązania.

Standardowym narzę­dziem sto­so­wa­nym przez więk­szość ana­li­ty­ków wyma­gań do prze­ka­za­nia wyma­gań na opro­gra­mo­wa­nie jest ich spe­cy­fi­ka­cja. Problem w tym, że pierw­szym testem tej spe­cy­fi­ka­cji jest tak na praw­dę dopie­ro ich implementacja.

Alternatywnym podej­ściem jest ana­li­za sys­te­mo­wa i mode­lo­wa­nie. Problem do roz­wią­za­nia to opra­co­wa­nie opro­gra­mo­wa­nia, któ­re zre­ali­zu­je cel zama­wia­ją­ce­go. Zamiast jed­nak, np. z pomo­cą wywia­dów, spi­sy­wać, nie pod­da­ją­ce się żad­nym testom, ocze­ki­wa­nia zama­wia­ją­ce­go, two­rzy­my dwa modele:

  1. naj­pierw model fir­my zama­wia­ją­ce­go by na nim prze­te­sto­wać zro­zu­mie­nie dzia­ła­nie samej fir­my i ewen­tu­al­nie ją nie­co zop­ty­ma­li­zo­wać”,
  2. model przy­szłe­go opro­gra­mo­wa­nia, któ­re ma zaspo­ko­ić potrze­by zama­wia­ją­ce­go czy­li zre­ali­zo­waw­szy jego cel.

Celem jest opro­gra­mo­wa­nie a dostaw­cy opro­gra­mo­wa­nia naj­mniej ryzy­ku­ją gdy dosta­ną jego spe­cy­fi­ku­ję czy­li goto­wy pro­jekt. Tak wiec prze­te­sto­wa­ny model opro­gra­mo­wa­nia reali­zu­ją­cy cel zama­wia­ją­ce­go jako wynik ana­li­zy sys­te­mo­wej sta­no­wi nic inne­go jak opis pro­duk­tu, któ­ry ma powstać. Oczywiście nikt nie pro­jek­tu­je od zera opro­gra­mo­wa­nia biz­ne­so­we­go bo to nie­roz­sąd­ne, wyko­rzy­stu­je się tak zwa­ne szkie­le­ty opro­gra­mo­wa­nia. O szkie­le­tach już było tu: Frameworks Introduction ? czy­li jak się psu­je dobre ERP. A teraz zapra­szam do obej­rze­nia tego co tu napi­sa­łem po moje­mu czy­li na dia­gra­mie 🙂 (tak zwa­ne mapy myśli cza­sa­mi sie przydają :)).

Warto tu zwró­cić uwa­gę na jed­ną rzecz: ewen­tu­al­ne zmia­ny roz­wią­za­nia i korek­ty mode­lu (czy­li pro­jek­tu) odby­wa­ją się nadal na eta­pie ana­li­zy i pro­jek­to­wa­nia, a wiec o rząd albo dwa taniej, niż pod­czas imple­men­ta­cji. Jest to głów­na prze­wa­ga tej meto­dy nad ana­li­zą w posta­ci sesji JAD ([[JAD, ang. Joint Application Development]] – ozna­cza współ­two­rze­nie apli­ka­cji, któ­re cza­sa­mi postrze­gam jako świa­do­me anga­żo­wa­nie klien­ta w pro­ces pro­jek­to­wa­nia by potem uczy­nić go współ­win­nym nie­po­wo­dze­nia) i opra­co­wy­wa­nia struk­tu­ral­nych dokumentów.

analiza systemowa oraz modelowanie jako jej główne narzędzie.

Jeżeli zre­zy­gnu­je­my z mode­li pozo­sta­je nam ryzy­kow­na sesja warsz­ta­to­wa (nie­jed­na):

Przygotowując warsz­tat zbie­ra­nia wyma­gań musisz być pewien, że zapro­sisz na nie­go wła­ści­we oso­by. Pamiętaj wte­dy, że:

  • Twoi bez­po­śred­ni klien­ci (pre­ze­si, dyrek­to­rzy, wła­ści­cie­le firm) czę­sto nie zna­ją tak napraw­dę potrzeb i kon­tek­stu pra­cy przy­szłych użyt­kow­ni­ków koń­co­wych zama­wia­ne­go systemu.
  • Użytkownicy koń­co­wi nie zawsze zna­ją i rozu­mie­ją potrze­bę biz­ne­so­wą dla two­rze­nia nowe­go oprogramowania.
  • Klienci i użyt­kow­ni­cy koń­co­wi nie zna­ją tech­no­lo­gii tak dobrze jak Ty i Twoja fir­ma, więc nie będą w sta­nie zro­zu­mieć szcze­gó­łów roz­wią­zań tech­nicz­nych w two­rzo­nym systemie.
  • Ty i Twoja fir­ma może­cie nie rozu­mieć w peł­ni potrzeb klien­ta i pro­ble­mu, któ­ry two­rzo­ne opro­gra­mo­wa­nie ma rozwiązać.

Co z tym zro­bić? Pamiętaj, aby zadbać, żeby przed­sta­wi­cie­le wszyst­kich powyż­szych grup bra­li udział w warsz­ta­tach, wów­czas inte­res każ­dej ze stron będzie repre­zen­to­wa­ny. (źr. ser­wis O wymaganiach)