Cykl tworzenia oprogramowania metodą zorientowaną na modele (Model Driven Development)

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Obawiam się, że temat jako­ści pro­ce­su two­rze­nia opro­gra­mo­wa­nia to never ending sto­ry” :). Ścierają się z sobą poglą­dy o tym czy to co spon­sor pro­jek­tu chce jest dobre czy złe, kom­plet­ne czy nie­kom­plet­ne itp.. a tak na praw­dę moim zda­niem pro­blem tkwi w tym, czy się to (two­rzyć opro­gra­mo­wa­nie) potra­fi robić czy nie. Podobnie jest każ­dej innej dziedzinie.

Dzisiaj co nie­co o for­ma­li­zmach i o tym, że od daw­na wia­do­mo jak wytwa­rzać dobrej jako­ści opro­gra­mo­wa­nie” tyl­ko to wyma­ga pew­nej wie­dzy i umie­jęt­no­ści. Nie nale­ży się bać, będę pisał do cze­go te for­ma­li­zmy słu­żą bez wni­ka­nia w nie, więc nie tyl­ko zawo­dow­cy z bran­ży” sa adre­sa­ta­mi tego tek­stu :). Na począ­tek jed­nak mała uwa­ga może raczej przy­po­mnie­nie dla upo­rząd­ko­wa­nia wie­dzy. Każdy pro­jekt biz­ne­so­wy, a wdro­że­nie opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie do takich nale­ży, to:

  1. posta­wie­nie problemu.
  2. zro­zu­mie­nie przy­czy­ny problemu,
  3. opi­sa­nie spo­so­bu roz­wią­za­nia problemu,
  4. zapro­jek­to­wa­nie narzę­dzia wspo­ma­ga­ją­ce­go roz­wią­za­nie problemu.

I dalej. Dobre opro­gra­mo­wa­nie to takie, któ­re poma­ga w roz­wią­za­niu pro­ble­mu lub, cza­sa­mi, nawet go roz­wią­zu­je. Problem pole­ga na tym, że umie­jęt­ność two­rze­nia roz­wią­zań tech­nicz­nych nie ozna­cza umie­jęt­no­ści roz­wią­zy­wa­nia pro­ble­mów biz­ne­so­wych. Dlatego dobry pro­gra­mi­sta nie ozna­cza powsta­nia dobre­go opro­gra­mo­wa­nia. Ktoś wcze­śniej musi ziden­ty­fi­ko­wać pro­blem (cel) i opra­co­wać roz­wią­za­nie. Powyższe czte­ry punk­ty to eta­py pro­jek­tu. Jeżeli to pro­jekt pro­gra­mi­stycz­ny to mamy odpowiednio:

  1. iden­ty­fi­ka­cja celu projektu,
  2. ana­li­za biznesowa,
  3. spe­cy­fi­ko­wa­nie wymagań,
  4. wyko­na­nie i implementacja.

Ścierają się zwo­len­ni­cy tezy, że wszyst­ko jest pro­stym rze­mio­słem, któ­re każ­dy może wyko­nać (w koń­cu podob­no nie świę­ci garn­ki lepią) z tezą, że ludzie dzie­lą się jed­nak na rze­mieśl­ni­ków i arty­stów. Zwolenników dru­giej tezy pozdra­wiam, tych pierw­szych zaś pytam: dla­cze­go ludzie tak wybrzy­dza­ją szu­ka­jąc np. foto­gra­fa na swój ślub zamiast dać apa­rat szwa­gro­wi, niech pstryka?

Jakiej wie­dzy i jakiej umie­jęt­no­ści tu potrze­ba i bra­ku­je jed­no­cze­śnie? Zacytuję jeden z poprzed­nich arty­ku­łów (to wynik ankiet):

Przyznajemy jed­nak, że dia­gra­my naj­le­piej wyja­śnia­ją­ce (uzu­peł­nia­ją­ce) wąt­pli­wo­ści zwią­za­ne z wyma­ga­nia­mi to mode­le pro­ce­sów i pro­to­ty­py, jed­nak nie sto­su­je­my ich. (Raport: Zarządzanie wyma­ga­nia­mi 2011)

Powyższe czte­ry eta­py omó­wię dalej, w kon­tek­ście pro­jek­tów wytwa­rza­nia oprogramowania.

Proces tworzenia oprogramowania czyli gdzie to modelowanie

opis techniczny ok(BIZNES ten roz­dział moż­na pominąć)

W 1989 roku (tak!) powsta­ło OMG (Object Management Group). Jest to kon­sor­cjum (obec­nie ok. 700 człon­ków), któ­re­go celem jest pro­mo­wa­nie i stan­da­ry­za­cja obiek­to­wych metod w inży­nie­rii opro­gra­mo­wa­nia (nie tyl­ko w kodowaniu/programowaniu o czym wie­lu zapo­mi­na!). Między inny­mi wzię­ło pod swo­je skrzy­dła nota­cję BPMN (mode­lo­wa­nie pro­ce­sów biz­ne­so­wych) i UML (mode­lo­wa­nie sys­te­mów w para­dyg­ma­cie obiek­to­wym). Ale nie tyl­ko nota­cja­mi się OMG zaj­mu­je. Jednym ze stan­dar­dów (i dobrych prak­tyk) pro­mo­wa­nych przez OMG jest pro­ces MDA (Model Driven Architecture), jest to pro­ces two­rze­nia opro­gra­mo­wa­nia dla biz­ne­su, opar­ty na mode­lo­wa­niu. Nie nale­ży tu mylić pro­ce­su two­rze­nia opro­gra­mo­wa­nia z pro­jek­tem two­rze­nia opro­gra­mo­wa­nia (to róż­ne rzeczy).

Jak wygląda MDA?

MDA Development sequence

Cały pro­ces two­rze­nia opro­gra­mo­wa­nia ma tu czte­ry fazy:

  1. opi­sa­nie tego cze­mu będzie to słu­ży­ło (model CIM, model orga­ni­za­cji, dla któ­rej powsta­nie opro­gra­mo­wa­nie, na tym mode­lu wska­zy­wa­ny jest zakres pro­jek­tu i nie ma na tym mode­lu żad­nej technologii!),
  2. opi­sa­nie co i jak to opro­gra­mo­wa­nie będzie robi­ło (model PIM, model logi­ki biz­ne­so­wej, któ­ra zosta­nie – to jest cel pro­jek­tu – odtwo­rzo­na w tym oprogramowaniu),
  3. opi­sa­nie tego jak wyko­nać to opro­gra­mo­wa­nie (model PSM, model kodu, któ­ry powsta­nie, tu wzo­rzec MVC: zakła­da­my, że war­stwy View i Controller już ist­nie­ją tu model PIM to Model),
  4. wytwo­rze­nie kodu pro­gra­mu (tu mie­ści się tak­że pla­no­wa­nie uży­cia goto­wych, dostęp­nych na ryn­ku kom­po­nen­tów, tak zwa­nych [[COTS ang. com­mer­cial off the shelf]], uży­cie frameworka/szkieletu MVC to tak­że COTS))

(MDA suge­ru­je auto­ma­ty­za­cje tego pro­ce­su ale to jest raczej jesz­cze przed nami)

Praktyka poka­zu­je, że naj­więk­szym ryzy­kiem jest przej­ście z CIM do PIM bo nie ist­nie­je jed­no­znacz­ne mapo­wa­nie CIM-PIM (zamia­na wie­dzy biz­ne­so­wej na pro­gra­mi­stycz­ną). I tu z pomo­cą przy­cho­dzi prak­ty­ka (zbiór zale­ceń, wzor­ce itp.) DDD, któ­ra mówi: sko­ro jest pro­blem z mapo­wa­niem to mode­luj­my tak, by mapo­wa­nie nie było potrzeb­ne! Modelujmy (ana­li­zuj­my) tak, by rola pro­jek­tan­ta opro­gra­mo­wa­nia (Analityk Systemowy) sta­ła się zbęd­na. To się da zro­bić pod warun­kiem, że Analityk Biznesowy poza pro­ce­sa­mi, zacznie mode­lo­wać tak­że opro­gra­mo­wa­nie” (w zasa­dzie przej­mu­je tu, peł­ni tak­że, rolę Analityka Systemowego). Jak? Po swo­je­mu! Swoim języ­kiem! Ale jak to potem prze­ka­zać pro­gra­mi­stom? Należy model biz­ne­su wyko­nać meto­da­mi obiek­to­wy­mi (DDD i ubi­qu­ito­us lan­gu­age)! Wykonać ten model tak, by był nie­ja­ko symu­la­cją bzi­ne­su (tak, pra­wie jak gra kom­pu­te­ro­wa). W koń­cu po to tak na praw­dę powsta­ły obiek­to­we języ­ki pro­gra­mo­wa­nia (a nie po to by kla­sa­mi opa­ko­wać kod;)).

Gdyby to się uda­ło to:

  1. Analityk Biznesowy sta­je się zara­zem pro­jek­tan­tem czę­ści opro­gra­mo­wa­nia opi­su­ją­cej logi­kę jaką ma ono realizować.
  2. Zbędne sta­je mapo­wa­nie PIM-PSM bo model PIM sta­je się czę­ścią PSM (two­rze­nie mode­lu PSM to tyl­ko opa­ko­wa­nie” logi­ki biz­ne­so­wej PIM ele­men­ta­mi ste­ro­wa­nia, bez­pie­czeń­stwa, inter­fej­sa­mi itp., przy­po­mi­nam, że to ponad 90% kodu!.
  3. Architektowi sys­te­mu w zasa­dzie pozo­sta­je opra­co­wać kom­plet­ny model PSM (owe bra­ku­ją­ce ponad 90% kodu!), zapla­no­wać jego imple­men­ta­cję i wyko­nać ją.

Tak więc DDD to spo­sób na wyeli­mi­no­wa­nie z pro­ce­su wytwa­rza­nia opro­gra­mo­wa­nia naj­bar­dziej ryzy­kow­ne­go eta­pu: prze­ło­że­nia wie­dzy biz­ne­so­wej (pro­ce­so­wej) na sys­te­mo­wą (obiek­to­wa). Niestety DDD jest czę­sto trak­to­wa­ne jako kolej­ny spo­sób pro­gra­mo­wa­nia” co postrze­gam jako poważ­ny błąd, i nie tyl­ko ja:

Domain Driven Design is an appro­ach that descri­bes the appro­ach to desi­gning the busi­ness lay­er. It doesn?t say much abo­ut the other lay­ers of an appli­ca­tion. The main advi­ce is to base the doma­in model on the lan­gu­age your custo­mer uses: the ubi­qu­ito­us lan­gu­age. This means that you sho­uld not have a method ?setAddress? on a Customer instan­ce if your custo­mer talks abo­ut ?regi­ster a relo­ca­tion?. In fact, the last appli­ca­tion I deve­lo­ped har­dly con­ta­ined any set­ter on any doma­in instan­ce at all. (źr. The misun­der­stan­ding of Domain Driven Design ? Dutchworks Blog / Dutchworks: Enterprise Java, Open Source, softwa­re solu­tions, Amsterdam.)

Tak więc jest meto­da. Praktyka poka­zu­je, że spraw­dza się. Praktyka poka­zu­je tak­że, że nie­ste­ty nie jest to łatwe (mode­lo­wa­nie biz­ne­su meto­da­mi obiek­to­wy­mi, tu nie­ste­ty nie da się powie­dzieć, że nie świę­ci garn­ki lepią”) dla­te­go powsta­ły pew­ne zale­ce­nia i wzor­ce pro­jek­to­we. Należy je zro­zu­mieć, nauczyć się sto­so­wać i sto­so­wać, co i tak nie zastą­pi pro­jek­to­wa­nia” czy­li twór­cze­go pier­wiast­ka w tym pro­ce­sie. Dokładnie tak samo jak nie da się auto­ma­tycz­nie two­rzyć kodu pro­gra­mu, do tego potrzeb­ni są (dobrzy) programiści.

Z prze­ko­rą powiem też, że nie wiem jak zwin­ność metod pro­gra­mi­stycz­nych ([[Agile Manifesto]]) mia­ła by ten pro­ces uzdro­wić i uczy­nić lep­szym (nadal uwa­żam, że brak doku­men­ta­cji, w tym opi­sa­nych mode­li, raczej psu­je pro­jek­ty co potwier­dza prak­ty­ka: ponad 70% pro­jek­tów to wpad­ki i jed­nym z głów­nych powo­dów był brak doku­men­tów opi­su­ją­cych biz­nes i pro­to­ty­py opro­gra­mo­wa­nia).

Polecana lite­ra­tu­ra (nie­ste­ty w j.ang.):

Na zakończenie

Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

  1. Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (model biz­ne­so­wy) oraz opis tego co ma powstać (opis, wyma­ga­nia na opro­gra­mo­wa­nie). Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
  2. Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: opra­co­wa­niu szcze­gó­łów archi­tek­tu­ry, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne), kodo­wa­niu oraz dostar­cze­niu i wdrożeniu.

Powyższe, tak udo­ku­men­to­wa­ny pro­jekt, pozwa­la tak­że osią­gnąć dodat­ko­wą korzyść: wie­dza orga­ni­za­cji” tkwi w wyko­na­nym dokład­nie opi­sie roz­wią­za­nia (mode­lu PIM) i deve­lo­per (wyko­naw­ca, dostaw­ca opro­gra­mo­wa­nia) nie może prze­jąć tej wie­dzy (pro­jek­tu) bez zgo­dy auto­ra, Analityka Biznesowego i spon­so­ra pro­jek­tu (pra­wo autor­skie, na wszel­ki wypa­dek nie zle­caj jed­nak deve­lo­pe­ro­wi pro­jek­to­wa­nia). Jest to sytu­acja ana­lo­gicz­na do budo­wy domu i jego pro­jek­tu: murarz nie może prze­jac pro­jek­tu bo nie jest jego auto­rem co nie prze­szka­dza mu do zrealizować.

Dodam po raz kolej­ny: nie ma tu żad­ne­go zna­cze­nia to czy jest to pro­jekt dedy­ko­wa­ny w cało­ści czy dostar­cze­nie goto­we­go opro­gra­mo­wa­nia z ele­men­ta­mi dopa­so­wa­nia (kasto­mi­za­cja). Gotowe opro­gra­mo­wa­nie (w wie­lu pro­jek­tach biz­ne­so­wych i tak dopa­so­wy­wa­ne) to po pro­stu goto­we kom­po­nen­ty oraz nowe, dedy­ko­wa­ne modu­ły. Dlatego piszę: nie kasto­sto­mi­zuj”, opisz to co potrze­bu­jesz, sprawdź czy coś goto­we­go na ryn­ku tu pasu­je a jeśli tak to kup to, wyko­naj bra­ku­ją­cą resztę.

Inne artykuły na podobny temat

Komentarze

  1. jacek2v 20 października 2011 at 16:39

    Nie nale­ży tu mylić pro­ce­su two­rze­nia opro­gra­mo­wa­nia z pro­jek­tem two­rze­nia opro­gra­mo­wa­nia (to róż­ne rzeczy).”
    vs
    Z prze­ko­rą powiem też, że nie wiem jak zwin­ność metod pro­gra­mi­stycz­nych (Agile Manifesto) mia­ła by ten pro­ces uzdro­wić i uczy­nić lepszym”
    🙂
    Chyba zno­wu nastą­pi­ło pomie­sza­nie pojęć ?

  2. jacek2v 20 października 2011 at 20:47

    Ponieważ Agile to meto­dy­ka zarzą­dza­nia pro­jek­ta­mi a MDA mode­lo­wa­nia pro­gra­mo­wa­nia. Agile mówi jak zarzą­dzać pro­ce­sem powsta­wa­nia opro­gra­mo­wa­nia, jak radzić sobie z ryzy­ka­mi i pro­ble­ma­mi (z cza­sem, zakre­sem, budże­tem). MDA mówi (for­ma­li­zu­je) o tym two­rzyć mode­le i dia­gra­my i jak przejść z jed­ne­go mode­lu (dia­gra­mu) do drugiego.
    MDA sku­pia się na for­ma­li­zmach i doku­men­ta­cji, zaś Agile na efek­tyw­nym zarzą­dza­niu procesem.
    Żeby dobrze pod­świe­tlić róż­ni­ce to nigdzie nie jest zabro­nio­ne uży­wa­nie MDA w Agile 🙂 Oczywiście będzie to wbrew idei lek­ko­ści, ale jeśli MDA komuś cięż­kie” nie będzie to nic nie stoi na prze­szko­dzie. Jedynymi wyznacz­ni­ka­mi czy coś jest zwin­ne są” ilość pra­cy i czas.

    • Jarek Żeliński 20 października 2011 at 22:22

      mam na myśli co inne­go: sko­ro bada­nia wska­zu­ją na to, że two­rze­nie zro­zu­mia­łych i prze­my­śla­nych mode­li (pro­to­ty­pów) to dro­ga do suk­ce­su a Agile mówi, że zamiast mode­li i ana­li­za roz­mo­wy z klien­tem i dąże­nie do celu” to jak to rozu­mieć? Pomieszania pojęć nie ma: MDA i pro­jek­ty to dwa róż­ne świa­ty, bo Projekt nie speł­nia defi­ni­cji pro­ce­su – pro­ces jest z defi­ni­cji powta­rzal­ny a pro­jekt jest z defi­ni­cji uni­kal­ny 🙂 czyż nie? Tak więc ja MDA z pro­jek­ta­mi w ogó­le nie mie­szam… Dodać wypa­da, że fak­tycz­nie MDA z natu­ry nie jest Agile (w rozu­mie­niu opi­sa­nym w Agile Manifesto).

    • jacek2v 21 października 2011 at 21:54

      …a Agile mówi, że zamiast mode­li i ana­li­za ?roz­mo­wy z klien­tem i dąże­nie do celu? to jak to rozumieć? ”
      Nie sły­sza­łem, żeby Agile coś takie­go mówi­ło. Agile wręcz sta­wia na cią­głą ana­li­zę i mini­ma­li­zu­je gadanie.

      pro­ces jest z defi­ni­cji powta­rzal­ny a pro­jekt jest z defi­ni­cji uni­kal­ny czyż nie?”
      Nie. Proces może być uni­kal­ny i pro­jekt może być powta­rzal­ny – tego nie blo­ku­ją defi­ni­cje w IT i tak wyni­ka z moje­go doświad­cze­nia w kil­ku­dzie­się­ciu projektach.

      Dodać wypa­da, że fak­tycz­nie MDA z natu­ry nie jest Agile (w rozu­mie­niu opi­sa­nym w Agile Manifesto).”
      Oczywiście, że nie jest bo to coś cał­kiem inne­go – ale o tym już pisałem 🙂

    • Jarek Żeliński 21 października 2011 at 22:16

      pro­po­nu­ję:
      stro­nę http://​agi​le​ma​ni​fe​sto​.org o Agile, co do defi­ni­cji pro­jek­tu i pro­ce­su pozo­sta­nę przy kla­sycz­nych, wymy­śla­nie swo­ich nowych pro­wa­dzi do utra­ty komu­ni­ka­cji. Ja nie uży­wam swo­ich” defi­ni­cji, to uła­twia wymia­nę myśli… że nie wspo­mnę o jako­ści doku­men­ta­cji (każ­dej tre­ści). Jeżeli uwa­ża Pan, że pro­jekt to rzecz tak­że powta­rzal­na a pro­ces to tak­że uni­kal­na to uzna­ję, ze wymie­ni­li­śmy poglą­dy i dal­sza dys­ku­sje nie jest potrzeb­na. Dalej: jako, że jestem gorą­cym zwo­len­ni­kiem jako­ści dys­ku­sji two­rzo­nej poprzez imien­ne pod­pi­sy­wa­nie się, wra­cam do tego zwy­cza­ju gdyż tak rewo­lu­cyj­ne tre­ści powin­ny być imien­nie zgłaszane. 

      Od tego momen­tu tyl­ko pod­pi­sa­ne imien­nie wypo­wie­dzi będą akceptowane.

    • Mateusz Kurleto 22 października 2011 at 11:03

      pole­cam bar­dzo cie­ka­wy arty­kuł umiesz­cza­ją­cy meto­dy­kę Agile (SCRUM) w pro­ce­sie TPM (RUP).
      Jak zawsze powta­rzam – nie ma nic złe­go w Agile, jeśli potra­fisz go uży­wać. Jak każ­de narzę­dzie spraw­dza się w obsza­rze swo­je­go zastosowania.

    • Jarek Żeliński 22 października 2011 at 18:43

      Prawdopodobnie serie nie­po­ro­zu­mień bio­rą się stąd, że fak­tycz­nie nie raz nie mówi się wprost czy sło­wo Agile w wypo­wie­dzi doty­czy zarzą­dza­nia pro­jek­tem czy pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia … ja dekla­ru­ję to drugie 🙂

  3. jacek2v 21 października 2011 at 22:32

    Ok. Jeśli mówi­my o defi­ni­cjach to:
    Ja też pole­cam Panu wczy­ta­nie się w mani­fest http://​agi​le​ma​ni​fe​sto​.org i poszu­ka­nie wzmian­ki o ?roz­mo­wy z klien­tem i dąże­nie do celu?
    Oraz pierw­sza z brze­gu defi­ni­cja pro­ce­su : http://​pl​.wiki​pe​dia​.org/​w​i​k​i​/​P​r​o​ces
    i pro­jek­tu: http://pl.wikipedia.org/wiki/Projekt_(zarządzanie) – pro­szę zwró­cić uwa­gę, że uni­kal­ność w pro­jek­cie odno­si się nie do same­go pro­jek­tu tyl­ko do produktu/celu projektu.

    Oczywiście te obie defi­ni­cje są ogól­ne i nie odno­szą się do IT, ale coś już mówią o tych terminach.
    Mnie nie inte­re­su­ją defi­ni­cje, a kon­kret­ne zasto­so­wa­nie w prak­ty­ce, dla­te­go pozdra­wiam sta­rym krót­ko­fa­lar­skim OVER 🙂

    Pozdrawiam
    Jacek Wojtkowski

    • Jarek Żeliński 21 października 2011 at 23:13

      Co do defi­ni­cji pro­jek­tów pole­cam PMI/Privce2, co do defi­ni­cji pro­ce­sów raczej lite­ra­tu­rę z zakre­su zarzą­dza­nia, Wikipedia, nie tyl­ko na uczel­niach, jest nie­po­waż­nym źró­dłem wie­dzy … i nie cho­dzi już o udo­wad­nia­nie prawd, a po pro­stu o nie wymy­śla­nie od nowa tego co już raz wymy­ślo­no (brzy­twa Ockhama…).. Over

  4. Jacek Rybicki 24 października 2011 at 22:43

    I znów temat jest spro­wa­dza­ny do dys­ku­sji o/nad Agile. Co do ?od daw­na wia­do­mo jak wytwa­rzać dobrej jako­ści opro­gra­mo­wa­nie?, to od daw­na wia­do­mo, że nie ist­nie­je jed­no uni­wer­sal­ne podejście.

    Przewrotnie tro­chę, cie­szę się że podej­ście kla­sycz­ne” znaj­du­je na tym blo­gu osto­ję. Redefiniowanie, po raz nie wia­do­mo któ­ry, pod­sta­wo­wych pojęć, w oba­wie, czy zba­cza­ją odro­bi­nę od obo­wią­zu­ją­ce­go nur­tu (a tam gdzie ja żyję, obo­wią­zu­je agi­le), przy­pra­wia mnie już o tiki nerwowe.
    Z przy­jem­no­ścią czy­tu­ję arty­ku­ły, ze świa­do­mo­ścią, że cho­ciaż z nie­któ­ry­mi pomy­sła­mi nie zga­dzam się (może tyl­ko w szcze­gó­łach), prze­ka­zu­ją one solid­ny ładu­nek wie­dzy o two­rze­niu oprogramowania.

    Co mnie moc­no zasta­na­wia, to kon­cep­cja ochro­ny wła­sno­ści inte­lek­tu­al­nej klien­ta, przez sepa­ro­wa­nie go od dostaw­cy opro­gra­mo­wa­nia. Hmm. Skądinąd wiem, że kon­cep­cje zarzą­dza­nia, orga­ni­za­cji pro­ce­sów, nie pod­le­ga­ją ochro­nie praw­nej, nie moż­na ich paten­to­wać. Mam też prze­ko­na­nie, że trans­fe­ry pra­cow­ni­ków są wystar­cza­ją­co sze­ro­kim kana­łem, przez któ­ry naj­bar­dziej skry­wa­ne kon­cep­cje mogą się przedostać.
    Jeżeli Klient oba­wia się nie­uczci­we­go Dostawcy, to jak Analityk zdo­by­wa zaufa­nie takie­go klien­ta? Czy Analityk, po dłu­go­trwa­łym pro­ce­sie odkry­wa­nia, razem z Klientem, szcze­gó­łów jego potrzeb, jest w sta­nie wyrzu­cić ten bagaż z pamię­ci, tak aby jakieś roz­wią­za­nia nie prze­śli­znę­ły się do kolej­ne­go projektu?

    • Jarek Żeliński 24 października 2011 at 23:28

      Wiele moich postów to popro­jek­to­we” prze­my­śle­nia. I po kolei kil­ka tłu­ma­czeń”.

      Agile: to moi klien­ci patrząc u sie­bie na kra­jo­braz po bitwie” kry­ty­ku­ją zwin­ne podej­ście jakie na nich ćwi­czo­no, ja raczej tu tyl­ko wyra­żam te opi­nie. Z mojej stro­ny mogę stwier­dzić: nie potra­fię obro­nić Agile u klien­tów, u któ­rych po bitwie” nie zosta­ło nic poza roz­grze­ba­nym, mało-przy­dat­nym sys­te­mem i żalem. Bo śla­dów po ana­li­zach, kon­cep­cjach itp. moż­li­wych do powtór­ne­go uży­cia nie ma, a za ana­li­zę cudze­go kodu nikt nie chce się łapać. Tezy, że kod doku­men­tu­je pro­jekt nie spraw­dza­ją się. 

      Moje, i nie tyl­ko moje kla­sycz­ne podej­ście, po pro­tu się spraw­dza i tyle tyl­ko mogę powie­dzieć. W kwe­stii od daw­na wia­do­mo jak wytwa­rzać dobrej jako­ści opro­gra­mo­wa­nie? to tyl­ko lite­ra­tu­ra (E.Yourdon i nie tyl­ko) i doświadczenie.

      W kwe­stii ochro­ny wła­sno­ści inte­lek­tu­al­nej. Niestety zno­wu pod­no­szą ten pro­blem klien­ci: oszu­ka­ni lub w inny spo­sób wyko­rzy­sta­ni w dre­na­żu wewnętrz­nej wie­dzy. Nie paten­tu­je się kon­cep­cji”, ale pra­wo autor­skie chro­ni szcze­gó­ło­wy opis algo­ryt­mu” zaś tajem­ni­ca przed­się­bior­stwa obej­mu­je spe­cy­ficz­ne meto­dy pra­cy” bo czym są pie­czo­ło­wi­cie wypra­co­wy­wa­ne regu­ły biz­ne­so­we? Klasycznym przy­kła­dem są sys­te­my sco­rin­go­we ban­ków: są pil­no­wa­ne bo nie raz sta­no­wią o prze­wa­dze ryn­ko­wej. I nie cho­dzi o to, że jakaś kon­cep­cja wyj­dzie wraz z byłym pra­cow­ni­kiem. Rzecz w tym, że ona i tak nie może sta­no­wić przed­mio­tu pro­jek­tu ani umo­wy. To jak z muzy­ką: co z tego, że ktoś sko­piu­je moje nuty sko­ro i tak nie może moje­go utwo­ru legal­nie publicz­nie wyko­ny­wać bo nara­ża się na konsekwencje. 

      Analityk zdo­by­wa zaufa­nie nie tym, że szyb­ko zapo­mi­na lub obie­cu­je, ze zapo­mni. Analityk zdo­by­wa (może) zaufa­nie a tym, że w umo­wie zapi­su­je prze­ka­za­nie praw mająt­ko­wych Zamawiającemu do wszyst­kie­go co u nie­go i dla nie­go zro­bi. Nie cho­dzi o to, że coś wiem. Chodzi o to, że to co wiem nie może być publicz­nie ofe­ro­wa­ne na rynku.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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