Polemika

Wstęp będzie na końcu…

Dla mnie model, dia­gram, rysu­nek nie jest niczym innym jak pustą obiet­ni­cą zre­ali­zo­wa­nia wyma­gań klienta.

A czym jest wobec tego, umowa?

dostar­czo­ny sys­tem po ​„rever­se enge­ene­rin­gu” kodu z powro­tem do UML nie ma nic wspól­ne­go z począt­ko­wym projektem

Sa dwa tego wytłu­ma­cze­nia: pro­jekt był zły lub wyko­naw­ca zigno­ro­wał projekt.

Model jest obiet­ni­cą bez pokrycia

To nie­ste­ty jest jed­nak tezą subiek­tyw­ną, wypa­da­ło by dodać ​„mój model”, ​„model” i tu jego autor. Testując kształt samo­cho­du czy samo­lo­tu w tune­lu aero­dy­na­micz­nym tak­że powie­my, że model jest obiet­ni­ca bez pokrycia?

Ja lubię odwo­ły­wać się w tym momen­cie do Biblii (sic!). Jak wie­my two­rzo­na była w róż­nych języ­kach i narze­czach, następ­nie prze­tłu­ma­czo­na na gre­kę i póź­niej na łaci­nę. Jeśli przyj­rzy­my się jej wer­sji w języ­ku pol­skim tłu­ma­czo­nym z gre­ki i łaci­ny, dosta­nie­my dwa doku­men­ty, któ­re róż­nią się w kil­ku klu­czo­wych frag­men­tach, a któ­rych inter­pre­ta­cja przez bibli­stów wywo­łu­je gorą­ce dys­ku­sje i kon­tro­wer­sje. Dla mnie dro­ga od mode­lu do dzia­ła­ją­ce­go sys­te­mu jest niczym innym jak trans­la­cją, pro­ce­sem w któ­rym giną szcze­gó­ły sta­no­wią­ce o kom­plet­no­ści systemu.

To porów­na­nie mnie dzi­wi, a nawet wca­le nie jeśli brać pod uwa­gę kto się tym porów­na­niem posłu­żył. Biblia to nie­spój­ny doku­ment wie­lu auto­rów, wybór z pośród więk­szej licz­by pism. Jest dokład­nym odpo­wied­ni­kiem naj­gor­szych prak­tyk w pro­jek­tach, gdy doku­men­ta­cje two­rzy zespól pisa­rzy a doku­ment wyni­ko­wy jest dzie­łem kie­row­ni­ka pro­jek­tu, któ­re­go pobud­ki są raczej poli­tycz­ne niż mery­to­rycz­ne. Jednak Biblia nie musi być spój­na, w prze­ci­wień­stwie to projektów.

Co do ana­lo­gii do samo­lo­tów, któ­ra jest mi szcze­gól­nie bli­ska ze wzglę­du na moją obec­ną fir­mę chciał­bym zauwa­żyć, że zanim pierw­szy samo­lot bra­ci Wright wzbił się w powie­trze, histo­ria lot­nic­twa pamię­ta cała masę pro­to­ty­pów, któ­re upa­dły nisko, zanim kolej­ny z nich wzbił się w powietrze…

Hm… czyż­by autor, powo­łu­jąc się na ten przy­kład, tkwił w tam­tych czas ze swo­im podej­ściem do two­rze­nia oprogramowania?

„model – sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (zamo­de­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rze­czy­wi­sto­ści.” (źr. wikipedia)

Przykro, ja już wyro­słem ze spo­łecz­nych źró­deł wie­dzy jakim jest Wikipedia i przy­to­czę defi­ni­cję z ksią­żek mają­cych kon­kret­ne­go auto­ra, Yourdon (celo­wo ten Pan, to facet zna­ny u pro­gra­mi­stów) pisze: ​„model to uprosz­cze­nie rze­czy­wi­sto­ści”. Polega to na sku­pie­niu się na rze­czach istot­nych w kon­tek­ście bada­ne­go pro­ble­mu (pole­cam tak­że Sienkiewicz, Analiza Systemowa, tam opis ana­li­zy i dowo­dze­nia tez meto­dą testo­wa­nia mode­li). Tak więc model pro­ce­su, to to, co robi Pan księ­go­wy z zanie­dba­niem kolo­ru jego garnituru.

Jestem też ogrom­nie cie­kaw jak wyglą­da testo­wa­nie dia­gra­mów i mode­li UML? Przyznaję, że w tym obsza­rze jestem kom­plet­nym igno­ran­tem i być może prze­spa­łem któ­reś spo­tka­nie w firmie.

Nie wiem co kole­ga prze­spał, jak i do cze­go się nie przy­kła­dał, ale mode­le się testu­je. Polecam: Sienkiewicz, Analiza sys­te­mo­wa, mate­ria­ły na , oraz kil­ka ​„skró­tów” https://it-consulting.pl//?s=dla+moich+klient%C3%B3w+. Testowanie opi­sa­niem tu: UML pro­ces…

Jestem cie­kaw co stoi za masą ​„kiep­skich ana­liz” i ​„beł­ko­tu”? Moim zda­niem dwie pro­ste przyczyny.Pierwsza to nie­jed­no­znacz­ność mode­li do mode­lo­wa­nia (czy­taj meta-języ­ków). Przy pomo­cy ​„przy­bli­żo­ne­go opi­su” opi­su­je­my ​„przy­bli­żo­ny aspekt rzeczywistości”.

Hm.. nie wiem co mam powie­dzieć, opro­gra­mo­wa­nie nie odtwa­rza żad­nej rze­czy­wi­sto­ści a jej opis, jeśli oczy­wi­ście pomi­nie­my gry kom­pu­te­ro­we. Dobry pro­gram ma kla­sę UserInfo a nie User. User sie­dzi przed kom­pu­te­rem. Owe kiep­skie ana­li­zy (beł­kot) to pró­by opi­sa­nia nie­jed­no­znacz­ną pro­zą cze­goś, co (kod w jakimś języ­ku pro­gra­mo­wa­nia) potem prze­pu­ści­my przez kompilator.

Druga przy­czy­na to testo­wa­nie mode­lu. Ale tutaj odda­je się cał­kiem w ręce mego adwer­sa­rza i cze­kam na pro­myk nadziei. Skoro mój opo­nent potrze­bu­je kart­ki papie­ru i 1000zł na prze­te­sto­wa­nie, to dla­cze­go dosta­ję taką ilość ​„beł­ko­tu”?

Tu jed­nak spraw­dza­ją się sło­wa, moje­go przy­ja­cie­la pro­gra­mi­sty, któ­ry mnie bar­dzo uczy poko­ry mawia­jąc, Jarek ja nie czy­tam ja pro­gra­mu­ję. Owo testo­wa­nie i 1000zł doty­czy­ło (co pod­trzy­mu­ję) jed­ne­go, prze­cięt­nie zło­żo­ne­go i opra­co­wa­ne­go już, przy­pad­ku uży­cia. Nie będę jed­nak się roz­wi­jał z tłu­ma­cze­niem co zna­czy ​„prze­cięt­nie złożony”.

Autor na zakoń­cze­nie spi­sał nie­mal­że memo­riał, któ­re­go tu nie będę cyto­wał. Wbrew posą­dze­niom czy­ta­łem cały jego arty­kuł (może to mnie jed­nak pogrąża).

A teraz wstęp

Na stro­nie 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/, jej autor bro­ni się przed moimi zarzu­ta­mi jakie mia­łem do tego co napi­sał (odno­śni­ki do moich tek­stów są na jego stronie).

Powyższe to cyta­ty i moje komen­ta­rze. Ostatni cytat:

gdy testo­wa­ny dia­gram sekwen­cji w kon­tek­ście ołów­ka i papie­ru nie wytrzy­mu­je zde­rze­nia z rze­czy­wi­sto­ścią tysię­cy zapy­tań na sekun­dę, przy ogra­ni­czo­nej, skoń­czo­nej, prze­pu­sto­wo­ści sie­ci nie wiń­my pro­gra­mi­stów. Bo łatwo jest umyć ręce od odpo­wie­dzial­no­ści, jed­nak ja wie­rzę w tzw. ​„owner­ship” i jed­na­ko­wą odpo­wie­dzial­ność za dostar­czo­ny pro­dukt na każ­dym pozio­mie dra­bi­ny pro­duk­cji oprogramowania

powa­lił dość moc­no moją wia­rę w tego pro­gra­mi­stę. Dlaczego? Bo szkol­ną (podob­no) wie­dzą jest to, że wyma­ga­nia funk­cjo­nal­ne, czy­li logi­ka biz­ne­so­wa sys­te­mu, oraz wyma­ga­nia poza­funk­cjo­nal­ne takie jak wydaj­ność, to odręb­ne rze­czy. Testowanie logi­ki biz­ne­so­wej sys­te­mu z pomo­cą dia­gra­mu sekwen­cji to testo­wa­nie logi­ki, wydaj­ność, owe tysią­ce zapy­tań na sekun­dę to wyma­ga­nia poza­funk­cjo­nal­ne. Tak wiec jeże­li ktoś myli testo­wa­nie tego czy wysta­wie­nie fak­tu­ry się uda na bazie zawar­to­ści maga­zyn­ku i reje­stru klien­tów z tym ile tych fak­tur będzie two­rzo­nych na sekun­dę, to ja nie wiem co mam powiedzieć…

Na zakoń­cze­nie dodam coś do mani­fe­stu: ludzie, sza­nuj­my na wza­jem swo­je kom­pe­ten­cje bo bez tego nie da się współ­pra­co­wać. Po dru­gie, nie tyl­ko w kon­tek­ście owych mode­li, któ­rych kole­ga nie doświad­czył: to że ktoś nigdy nie widział czar­ne­go łabę­dzie nie sta­no­wi żad­ne­go dowo­du na jego nie­ist­nie­nie. Dodam od sie­bie: to że ktoś cze­goś nie potra­fi nie zna­czy, ze to nie moż­li­we. By nie budzić zbęd­nych emo­cji: obec­nie nie potra­fię już dobrze pro­gra­mo­wać (co by to nie mia­ło zna­czyć) ale w swym roz­sąd­ku nie negu­ję ist­nie­nia oprogramowania.

Jakie to było pięk­ne gdy do moje­go miesz­ka­nia wpa­dła eki­pa remon­to­wa: Pani pro­jek­tant oraz sto­larz, murarz i hydrau­lik. Pani pro­jek­tant wypy­ta­ła mnie co na co dzień robię w poko­ju, łazien­ce, sypial­ni i nary­so­wa­ła to cze­go powi­nien się spo­dzie­wać po remon­cie. To był załącz­nik do umo­wy z fachow­ca­mi. Ci zaś, zamiast psio­czyć na pomy­sły Pani pro­jek­tant, wysi­li­li swo­je inży­nier­skie umy­sły i z kil­kom drob­ny­mi korek­ta­mi, stwo­rzy­li to co zosta­ło nary­so­wa­ne. Nie odwo­dzi­li mnie od malo­wa­nia pod kątem w dwa kolo­ry sza­fy, nie wma­wia­li mi, że nikt tak nie robi. Tego od nich ocze­ki­wa­łem… sza­cun­ku fachow­ców dla Pani pro­jek­tant i sza­cun­ku Pani pro­jek­tant dla fachow­ców. Jej doświad­cze­nie i zna­jo­mość ogra­ni­czeń tech­no­lo­gii budzi­ły podziw. Ale pro­jek­tu­jąc cho­dzi o ogra­ni­cze­nia tech­no­lo­gii a nie ludzi.

Słowa kluczowe: ,

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 9 komentarzy

  1. Matthias 24 maja 2011 Odpowiedz

    Szczerze jestem cie­kaw jak wyglą­da­ła­by ana­li­za takich pro­duk­tów jak np. sys­tem do prze­li­cza­nia insta­la­cji ciepłej/zimnej wody czy też cen­tral­ne­go ogrze­wa­nia. O ile moż­na sobie pozwo­lić na takie sza­leń­stwo pro­jek­to­we przy pisa­niu apli­ka­cji stric­te biz­ne­so­wych (takich jak na przy­kład wysta­wia­nie fak­tur czy obsłu­ga maga­zy­nu tudzież blo­gi) to pro­gra­my obli­cze­nio­we mają algo­ryt­my na tyle zło­żo­ne, że ich wyra­ża­nie ​„na blocz­kach” ma nikłe szan­se powo­dze­nia. W tym duchu chciał­bym kie­dyś zoba­czyć jak nary­so­wać np. sche­mat dzia­ła­nia sie­ci neu­ro­no­wej w obrę­bie pro­jek­tu obli­cze­nio­we­go. Serio! Nigdy sie nad czymś takim nie zasta­na­wia­łem a może war­to było­by zoba­czyć taki twór. Albo jesz­cze cie­kaw­sza rzecz i z pew­no­ścią bliż­sza każ­de­mu: arkusz kal­ku­la­cyj­ny z jego mno­go­ścią wbu­do­wa­nych formuł.

    1. Jarek Żeliński 25 maja 2011

      Nieco ponad rok temu poma­ga­łem pro­jek­to­wać sys­tem nali­cza­nia kar za emi­sje szko­dli­wych sub­stan­cji. Oplata jest wyni­kiem zebra­nia w fir­mie (np. kopal­nia, rafi­ne­ria) danych o wszyst­kich emi­tu­ją­cych urzą­dze­niach, rodza­ju sub­stan­cji dla każ­de­go oraz tego w jakich budyn­kach są zain­sta­lo­wa­ne. Do tego urzą­dze­nia te moż­na prze­no­sić pomię­dzy budyn­ka­mi a nawet pla­ców­ka­mi danej fir­my. Zaangażowano mnie, bo pra­cu­ją­cy nad mega wzo­rem na wyso­kość kary i mega zapy­ta­niem SQL infor­ma­ty­cy zosta­li zje­dze­ni przez wła­sny kod nad któ­rym prze­sta­li pano­wać (a nie byli to amatorzy). 

      Poza zło­żo­no­ścią prze­pi­sów docho­dzi to, że co roku licz­ba kar się zmie­nia, staw­ki są mody­fi­ko­wa­ne, poja­wia­ją się nowe kary a do tego moż­li­we jest han­dlo­wa­nie na ryn­ku zapa­sa­mi limi­tów emi­sji. W dużym skró­cie (wyni­ki pra­cy pouf­ne bo to, opro­gra­mo­wa­nie, pro­dukt tej fir­my) opra­co­wa­łem model dzie­dzi­no­wy opar­ty w zasa­dzie w 100% na DDD, testy popraw­no­ści moż­li­we były na dia­gra­mach zanim powsta­ła choć­by linij­ka kodu, wiel­kie zło­żo­ne zapy­ta­nia SQL znik­nę­ły, a zamiast wiel­kie­go wzo­ru na osta­tecz­ną wyso­kość kary poja­wi­ła się sekwen­cja pro­stych metod„ któ­rych dzia­ła­nie pole­ga­ło na ​„doga­da­niu się” obiek­tów dzie­dzi­ny odpo­wie­dzial­nych za wie­dzę o emi­sji każ­de­go emi­tu­ją­ce­go obiek­tu. Każdy obiekt miał inter­fejs pozwa­la­ją­cy na wpro­wa­dza­nie ręcz­ne danych i moż­li­wość natych­mia­sto­we­go przej­ścia na czy­ta­nie z czuj­ni­ków (sys­tem był w trak­cie tworzenia). 

      To co opi­sa­łeś do wła­śnie dosko­na­łe przy­kła­dy pro­ble­mów, w któ­rych meto­dy obiek­to­we i wcze­śniej­sze ich pro­jek­to­wa­nie się spraw­dza­ją, sys­te­my biz­ne­so­we są ​„nud­ne” przy tego rodza­ju pro­ble­mach. Jednak nie zapo­mi­naj, że np. pro­gno­zo­wa­nie logi­sty­ki trans­por­tu to nie jest try­wial­ny pro­blem podob­nie jak nali­cze­nie wyna­gro­dze­nia w tym kra­ju (to tak­że kie­dyś upro­ści­łem pew­nej fir­mie z mega wzo­rów do pro­stych obiek­to­wych sekwen­cji). Problemy biz­ne­so­we są zło­żo­ne jako narzę­dzia dla ludzi i zapew­niam, Cię że nie są try­wial­ne ale fak­tycz­nie cie­ka­we wyzwa­nia to sys­te­my jak ten powy­żej. I jest to wyzwa­nie w 100% pro­jek­to­we a nie pro­gra­mi­stycz­ne (pro­blem z nali­cza­niem wyna­gro­dzeń to nie pro­blem zako­do­wa­nia a pro­blem zapro­jek­to­wa­nia jak to liczyć!). 

      W kwe­stii arku­sza kal­ku­la­cyj­ne­go (np. Excel) to w 100% obiek­to­we pro­jek­ty, pole­cam stro­ny MSDN, od pew­ne­go cza­su są bar­dzo kształ­cą­ce: Microsoft od cza­su jak powstał .NET stał się bar­dzo wyso­kiej kla­sy part­ne­rem metod obiek­to­wych (nie­ste­ty nie biu­ro w Polsce). Polecam zacząć od tego: http://​msdn​.micro​soft​.com/​e​n​-​u​s​/​l​i​b​r​a​r​y​/​d​d​4​0​9​4​2​3​(​v​=​V​S​.​100).aspx

    2. Jarosław Żeliński 22 listopada 2022

      „O ile moż­na sobie pozwo­lić na takie sza­leń­stwo pro­jek­to­we przy pisa­niu apli­ka­cji stric­te biz­ne­so­wych (takich jak na przy­kład wysta­wia­nie fak­tur czy obsłu­ga maga­zy­nu tudzież blo­gi) to pro­gra­my obli­cze­nio­we mają algo­ryt­my na tyle zło­żo­ne, że ich wyra­ża­nie ?na blocz­kach? ma nikłe szan­se powodzenia.”

      i pro­blem w tym, że robi się to od dwóch dekad w prze­my­śle, z uży­ciem UML i potem jego roz­sze­rze­niem SysML.

      „Serio! Nigdy się nad czymś takim nie zasta­na­wia­łem a może war­to było­by zoba­czyć taki twór.”
      może w koń­cu war­to zacząć.. 😉 

      https://​www​.scien​ce​di​rect​.com/​s​c​i​e​n​c​e​/​a​r​t​i​c​l​e​/​a​b​s​/​p​i​i​/​S​1​4​7​4​0​3​4​6​1​4​0​0​0​342

  2. Maciej Gawinecki 4 czerwca 2011 Odpowiedz

    Być może błęd­nie poj­mu­ję funk­cję ana­li­ty­ka sys­te­mo­we­go, ale dla mnie pro­jekt stwo­rzo­ny przez ana­li­tyks musi wziąć pod uwa­gę zarów­no wyma­ga­nia funk­cjo­nal­nych, jak wyma­ga­nia nie­funk­cjo­nal­ne (klien­ta) i (nasze) moż­li­wo­ści tech­nicz­ne. Dobry pro­jekt jest wypad­ko­wą tych czyn­ni­ków i powsta­je w wyni­ku dialogu/iteracji mię­dzy tymi czyn­ni­ka­mi. Oczywiście na wyso­kim pozio­mie abs­trak­cji te czyn­ni­ki mogą wyda­wać się odręb­ne, wszak trze­ba jasno okre­ślić naj­pierw logi­kę biz­ne­so­wą (np. sys­tem ma spraw­dzać czas na maga­zy­nie) i wyma­ga­nia funk­cjo­nal­ne (sys­tem ma to robić dla 2000 klien­tów na godzi­nię). Natomiast, szcze­gó­ło­wa spe­cy­fi­ka­cja tech­nicz­na powin­na uwzględ­nia oba typy wymagań. 

    Joel Spolsky daje tutaj dobry przy­kład na pod­sta­wie swo­je­go doświad­cze­nia przy pro­jek­cie jako mena­dżer pro­gra­mu MS Excel (http://​www​.joelon​so​ftwa​re​.com/​i​t​e​m​s​/​2​0​0​9​/​0​3​/​0​9​.​h​tml):

    „The first thing I had to do was figu­re out what custo­mers needed, which I did by tal­king to as many custo­mers as I could until I star­ted to get kind of bored becau­se I kept hearing the same thing. I spent a lot of time tal­king to the deve­lop­ment team to figu­re out what would be possi­ble and reaso­na­ble to imple­ment in a sin­gle 18 month rele­ase, and I spent a lot of time tal­king to the Visual Basic team to see if they could sup­ply a com­pi­ler, code edi­tor, and dia­log box edi­tor that could be used in Excel for our macro language.”

    1. Jarek Żeliński 4 czerwca 2011

      Być może trud­no okre­ślić jed­ną gra­ni­cę. Osobiście jestem zwo­len­ni­kiem tezy, by na eta­pie ana­li­zy i pro­jek­to­wa­nia powsta­ła ​„wizja” roz­wią­za­nia, pro­jekt nie ogra­ni­czo­ny tech­no­lo­gią (ale logicz­nie spój­ny). Teraz rola inży­nie­ra: ma okre­ślić koszt i moż­li­wość reali­za­cji tej wizji. Po tej wery­fi­ka­cji powsta­je zakres pro­jek­tu. Ten etap bywa nie raz nazy­wa­ny ​„stu­dium wyko­ny­wal­no­ści”. Moim zda­niem sta­wia­nie ogra­ni­czeń (nie raz bar­dzo subiek­tyw­nych) już na eta­pie ana­li­zy i pro­jek­to­wa­na pro­wa­dzi do powsta­wa­nia tego co za Gierka (kto pamię­ta, lata 70-te :)) dopro­wa­dzi­ło do tego, że wszyst­kie dom­ki jed­no­ro­dzin­ne były sześcianami ;).

      Ale jed­no jest praw­dą: ana­li­tyk pro­jek­tant MUSI bar­dzo dobrze rozu­mieć tech­no­lo­gię, któ­rej sta­wia wymagania. 

    1. Jarosław Żeliński 18 listopada 2019

      Pierwszy to:
      dla moich klien­tów. Drugi to nie­ste­ty stro­na moje­go adwer­sa­rza, nie­ste­ty już usu­nię­ta, zosta­ły tyl­ko cyta­ty w powyż­szym artykule.

Dodaj komentarz

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