Tag: TDD

TDD – czy same testy to wymagania?

3 komentarze

Na nie­daw­no zakoń­czo­nej kon­fe­ren­cji beIT orga­ni­zo­wa­nej na Politechnice Gdańskiej przez Wydział Elektrotechniki, Telekomunikacji i Informatyki, wygło­si­łem refe­rat zaty­tu­ło­wa­ny Filozofia czy­li Aplikacja jako ele­ment biz­ne­so­wej rze­czy­wi­sto­ści (a nie gra kom­pu­te­ro­wa). Przesłanie tej pre­zen­ta­cji to:

Oprogramowanie bar­dzo czę­sto zastę­pu­je kon­struk­cje rze­czy­wi­ste takie jak zega­rek, kar­to­te­ka, biblio­te­ka, księ­gi han­dlo­we, pro­gra­ma­tor pral­ki i wie­le innych rze­czy. Dlatego ana­li­za powin­na pole­gać na zro­zu­mie­niu i udo­ku­men­to­wa­niu mecha­ni­zmu dzia­ła­nia ​„tego cze­goś” a nie jedy­nie na spi­sa­niu zewnętrz­nych oznak tego dzia­ła­nia i zarzą­dza­nie tym spisem. 

Referat miał lek­kie pod­ło­że filozoficzne :).

Ten arty­kuł nie będzie jed­nak powtó­rze­niem refe­ra­tu (wyżej link do pobra­nia). Do jego napi­sa­nia skło­ni­ło mnie jed­no z pytań z sali:

„Stosujemy TDD, czy to nie wystar­czy? Po co więc robić to o czym Pan mówi?”

Otóż odpo­wiedź brzmia­ła: TDD nie zastę­pu­je opi­su mecha­ni­zmu dzia­ła­nia. Innymi sło­wy: sam zestaw testów bar­dzo czę­sto nie sta­no­wi żad­nej infor­ma­cji o tym co ma powstać.

Niedawno pisa­łem:

Mechanizm jed­nak to nie zawsze tyl­ko same regu­ły, bar­dzo czę­sto (prak­tycz­nie zawsze dla nie­try­wial­nych sys­te­mów) powi­nien powstać dia­gram poka­zu­ją­cy wewnętrz­ną budo­wę (archi­tek­tu­rę) sys­te­mu, zestaw kom­po­nen­tów odpo­wie­dzial­nych za logi­kę reali­zo­wa­nia tych reguł (a jed­ną z nich jest np. ?treść doku­men­tów musi być zapa­mię­ty­wa­na z moż­li­wo­ścią przy­wo­ła­nia jej w dowol­nym momen­cie?). Taki dia­gram nazy­wa się Model dzie­dzi­ny. Jak go two­rzyć pisa­łem nap. w arty­ku­le Model dzie­dzi­ny jako wyma­ga­nie. (Źródło: Model To Mechanizm | | Jarosław Żeliński IT-Consulting)

A teraz jako przy­kład przy­to­czę dość zło­żo­ny kom­po­nent wie­lu sys­te­mów (pogru­bie­nie moje):

Jak dzia­ła sco­ring w Banku. Klient zain­te­re­so­wa­ny uzy­ska­niem kre­dy­tu wypeł­nia wnio­sek kre­dy­to­wy dla wybra­ne­go pro­duk­tu kre­dy­to­we­go. Dane z wnio­sku reje­stro­wa­ne są w sys­te­mie infor­ma­tycz­nym, któ­ry wspo­ma­ga pro­ces obsłu­gi wnio­sków kre­dy­to­wych w Banku. Podczas prze­twa­rza­nia wnio­sku nastę­pu­je wery­fi­ka­cja danych oraz zapy­ta­nie o auto­ma­tycz­ną reko­men­da­cję kre­dy­to­wą kie­ro­wa­ną do sil­ni­ka decy­zyj­ne­go. Silnik decy­zyj­ny wyko­nu­je zde­fi­nio­wa­ny w posta­ci reguł prze­twa­rza­nia algo­rytm sco­rin­go­wy: gro­ma­dzi dodat­ko­we infor­ma­cje z dostęp­nych źró­deł (np. Biuro Informacji Kredytowej SA, bazy nie­so­lid­nych klien­tów oraz dowo­dów zastrze­żo­nych ? MIG BR, MIG DZ), wyzna­cza wskaź­ni­ki, okre­śla przy­dział do klas ryzy­ka oraz wyli­cza oce­nę punk­to­wą w opar­ciu o kar­ty sco­rin­go­we. (Źródło: Scoring – meto­da oce­ny wia­ry­god­no­ści kre­dy­to­wej – ERP​-view​.pl – ERP, CRM, MRP, Business Intelligence, MRP)

Odpowiadając na pyta­nie o TDD powiem tak: nie da się ​„jed­no­znacz­nie zamó­wić” Systemu sco­rin­go­we­go, poda­jąc jedy­nie par­tię danych wej­ścio­wych i spo­dzie­wa­nych danych wyj­ścio­wych. Testy moż­na opra­co­wać zna­jąc mecha­nizm dzia­ła­nia tego sys­te­mu, two­rzy­my wte­dy repre­zen­ta­tyw­ny zestaw testów ​„pokry­wa­ją­cy cały kod”, o ile zna­my struk­tu­rę tego kodu (pro­jekt). Sam kod nie musi ist­nieć w momen­cie pro­jek­to­wa­nia tych testów, ale opra­co­wa­ny mecha­nizm tak, bo jak już pisa­łem ​„model dzie­dzi­ny to struk­tu­ra kodu reali­zu­ją­ce­go logi­kę biz­ne­so­wą wraz z metodami”.

Można tu powie­dzieć, że nie każ­dy sys­tem to zło­żo­ność sys­te­mu sco­rin­go­we­go. To praw­da, ale to co nazy­wa­my biz­ne­sem to regu­ły biz­ne­so­we, mecha­nizm dzia­ła­nia orga­ni­za­cji, a ten nigdy nie jest try­wial­ny. Reguły udzie­la­nia upu­stów, regu­ły przy­dzie­la­nia kre­dy­tów kupiec­kich, regu­ły nagra­dza­nia w sys­te­mach lojal­no­ścio­wych, regu­ły roz­li­cza­nia kosz­tów i wie­le, wie­le innych w pra­wie każ­dej fir­mie, orga­ni­za­cji czy insty­tu­cji publicznej.

Prawdopodobieństwo tego, że powsta­nie ​„popraw­ne” opro­gra­mo­wa­nie tyl­ko na pod­sta­wie zapi­su sze­re­gu ​„zewnętrz­nych obser­wa­cji” (bo czym są wyma­ga­nia jako zapis burz mózgów, ankiet, wywia­dów, itp.?) jest tym bar­dziej bli­skie zeru im bar­dziej orga­ni­za­cja ma zło­żo­ny mecha­nizm dzia­ła­nia (czy­li większość).

Zjawisko to jest zna­ne już od dzie­siąt­ków lat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

Dlatego roz­wią­za­nie nie­try­wial­ne­go pro­ble­mu nie pole­ga na spe­cy­fi­ko­wa­niu tego co zna­my, a na pod­ję­ciu pró­by zapro­jek­to­wa­nia roz­wią­za­nia. Tym pro­jek­tem nie jest jed­nak ​„opis reak­cji syst­se­mu na bodź­ce” (czar­na skrzyn­ka). Projektem jest opi­sa­ny (jed­no­znacz­nie udo­ku­men­to­wa­ny) mecha­nizm dzia­ła­nia roz­wią­za­nia (bia­ła skrzynka).

Dlatego wyma­ga­nia spe­cy­fi­ku­je­my sku­tecz­nie poprzez pro­jekt pro­duk­tu a nie poprzez listę cech pro­duk­tu. Zamówienie dla deve­lo­pe­ra powin­no zawie­rać pro­jekt a nie wizu­ali­za­cję efek­tu koń­co­we­go, dokład­nie tak jak w bran­ży budow­la­nej, elek­tro­nicz­nej czy nawet mecha­nicz­nej (nawet wyko­naw­ca wału kor­bo­we­go dosta­je rysun­ki tech­nicz­ne a nie roz­wle­kłą proś­bę o faj­ny wał do samochodu).

Zilustrować to moż­na tak:

Wymagania

  1. Wymagania biz­ne­so­we zgła­sza biz­nes, są one for­mą opi­su i kon­se­kwen­cją pro­ble­mu biz­ne­so­we­go, wyma­ga­nia wobec roz­wią­za­nia to usta­lo­ny zakres projektu.
  2. Jeżeli jest to pro­jekt z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, ma powstać opro­gra­mo­wa­nie opi­sa­ne z uży­ciem Przypadków uży­cia i Modelu dziedziny.
  3. Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Kto ma opra­co­wać to ostat­nie? Programista? A na jakiej pod­sta­wie, sko­ro ​„nie zna tego biz­ne­su” (to pro­gra­mi­sta a nie ana­li­tyk biz­ne­so­wy)? Czy same przy­pad­ki uży­cia opi­su­ją regu­ły (mecha­nizm dzia­ła­nia) dzia­ła­nia syst­se­mu sco­rin­go­we­go czy sys­te­mu upu­stów w pro­mo­cji (to jed­na licz­ba, war­tość upu­stu, na fak­tu­rze)? Nie. Czy da się na bazie par­tii testów (czy­li skoń­czo­nej, ale z regu­ły nie­zu­peł­nej liście bodziec-odpo­wiedź) stwo­rzyć cokol­wiek? Mało kie­dy. Oznacza to, że wyma­ga­nia zebra­ne tyl­ko jako przy­pad­ki uży­cia ​„mało kie­dy” dają szan­sę na powsta­nie opro­gra­mo­wa­nia ​„za pierw­szym razem”, tu pro­to­ty­pów nie jest nigdy prze­wi­dy­wal­na. To dla­te­go meto­dy zwa­ne zwin­ny­mi, bazu­ją­ce wyłącz­nie na user sto­ry i pro­to­ty­pach, nada­ją się do pro­ble­mów pro­stych. Kompletnie nie spraw­dza­ją się w przy­pad­kach zło­żo­nych sys­te­mów, rozu­mia­nych jako zło­żo­ne mecha­ni­zmy. Te ostat­nie trze­ba nie raz ​„od zera” odkryć i opisać.

Paradygmat i metody obiektowe

Kluczem metod obiek­to­wych (i para­dyg­ma­tu obiek­to­we­go) jest her­me­ty­za­cja. Oznacza to, że zło­żo­ność obiek­tu ​„z zewnątrz” nie jest zna­na nigdy, nie ma zna­cze­nia wiel­kość obiek­tu (mała kla­sa czy mega-kom­po­nent), na zewnątrz postrze­ga­ny jest wyłącz­nie jako inter­fejs. Rozważania na począt­ku poka­za­ły, że odpo­wie­dzi na bodź­ce to ocze­ki­wa­ne (wyma­ga­ne) cechy roz­wią­za­nia, któ­re jed­nak nie deter­mi­nu­ją jego mechanizmu.

Oprogramowanie poma­ga­ją­ce w nauce tablicz­ki mno­że­nia do 100, może zawie­rać sta­tycz­ną tabli­cę zna­ną z ostat­nich stron sta­rych zeszy­tów, a może to być mecha­nizm będą­cy imple­men­ta­cją algo­ryt­mu mno­że­nia. Po pierw­sze zestaw testów, jak widać, nie deter­mi­nu­je żad­nej z tych metod imple­men­ta­cji. Po dru­gie spe­cy­fi­ka­cja w pierw­szym wypad­ku będzie ​„duża” (kosz­tow­na), w dru­gim bar­dzo pro­sta. Po trze­cie roz­wi­ja­nie (tablicz­ka mno­że­nia do 1000) opro­gra­mo­wa­nia w wer­sji z tabli­cą sta­tycz­ną będzie znacz­nie droż­sze niż pier­wot­ne wytwo­rze­nie wer­sji z mno­że­niem do 100. W dru­gim przy­pad­ku będzie pole­ga­ło wyłącz­nie na zdję­ciu blo­ka­dy mno­że­nia liczb więk­szych niż 10.

Tak więc co z tym TDD? Popatrzmy na to jak jest definiowane:

Co to jest Test Driven Development

Test Driven Development, czy­li TDD, to tech­ni­ka two­rze­nia opro­gra­mo­wa­nia ste­ro­wa­na przez testy. Tworzenie kodu skła­da się z wie­lo­krot­nie wyko­ny­wa­nych trzech głów­nych kroków:

  1. Stworzenie testu jed­nost­ko­we­go, któ­ry powi­nien być moż­li­wie naj­prost­szy, aby unik­nąć moż­li­wo­ści popeł­nie­nia błę­du w samym teście. Test ma spraw­dzać funk­cjo­nal­ność, któ­ra będzie imple­men­to­wa­na w kro­ku 2.
  2. Implementacja funk­cjo­nal­no­ści ? two­rzy­my funk­cjo­nal­ność, któ­rą chce­my zaim­ple­men­to­wać. Funkcjonalność ta powin­na speł­niać zało­że­nia testu jed­nost­ko­we­go, a wyko­na­nie testu jed­nost­ko­we­go powin­no koń­czyć się sukcesem.
  3. Refaktoryzacja, czy­li porząd­ki w stwo­rzo­nej funk­cjo­nal­no­ści. Ma to na celu upo­rząd­ko­wa­nie kodu, tak aby speł­nio­ne były stan­dar­dy. Czynności wyko­ny­wa­ne w tym kro­ku nie mogą zmie­nić wyni­ku testów.

Źródło: Test Driven Development

Pod poję­ciem funk­cjo­nal­ność tu rozu­mia­ny jest ​„ocze­ki­wa­ny efekt”, bo test nie jest niczym innym. Czy testy to są (zastę­pu­ją) pro­jekt wewnętrz­nej logi­ki? W przy­pad­kach try­wial­nych pew­nie tak, tam gdzie logi­ka jest pro­sta lub nie wystę­pu­je (przy­pad­ki uży­cia typu CRUD), albo tam gdzie ​„logi­ka” jest ​„powszech­nie zna­na” zna ją tak­że pro­gra­mi­sta (np. spo­sób dzia­ła­nia zegara).

Jednak sys­tem o nie­try­wial­nej logi­ce dzia­ła­nia, nie da się wyspe­cy­fi­ko­wać w posta­ci skoń­czo­nej (lub roz­sąd­nie krót­kiej) listy bodziec-efekt (np. przy­kła­do­wych par­tii gry w sza­chy). W jed­nej ze swo­ich ksią­żek Martin Fowler napi­sał, że żad­na ilość godzin fil­mu znad sto­łu bilar­do­we­go, jako wyma­ga­nie, nie da w efek­cie nawet namiast­ki dobrej gry w bilar­da. Ale sche­mat sto­łu, wymia­ry kul, kija oraz pra­wa fizy­ki rzą­dzą­ce ruchem kul, pozwo­lą na napi­sa­nie wręcz dosko­na­łej symu­la­cyj­nej gry. Taki opis to wła­śnie model dzie­dzi­ny gry w sza­chy, dokład­ny opis mecha­ni­zmu tego co dzie­je się na sto­le bilardowym.

Ostatnie pyta­nie brzmia­ło: Jak przejść od wyma­gań biz­ne­so­wych do Przypadków uży­cia i mode­lu dzie­dzi­ny i kto ma tego dokonać?

Odpowiedź na to pyta­nie zawie­ra pewien arty­kuł, napi­sa­ny w 2014 roku na nie­co inny temat:

…rolą ana­li­ty­ka biz­ne­so­we­go nie jest spi­sa­nie prze­bie­gu dzie­sią­tek wywia­dów i setek indy­wi­du­al­nych wyma­gań. Nie mają więk­sze­go sen­su doku­men­ty na dwa, trzy tysią­ce stron (nikt ich nie czy­ta!). Rolą ana­li­ty­ka biz­ne­so­we­go jest prze­ana­li­zo­wa­nie dostęp­nych doku­men­tów, infor­ma­cji, i stwo­rze­nie opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji oraz opi­su roz­wią­za­nia, narzę­dzia mogą­ce­go uspraw­nić dzia­ła­nie orga­ni­za­cji. Opisu zawie­ra­ją­ce­go regu­ły biz­ne­so­we, prze­twa­rza­ne infor­ma­cje (wzo­ry doku­men­tów) oraz listą usług jakie ma świad­czyć pla­no­wa­na do wdro­że­nia apli­ka­cja wraz z opi­sem tego, jak te usłu­gi mają być reali­zo­wa­ne (umie­jęt­no­ści, któ­re moż­na zauto­ma­ty­zo­wać). Sens mają więc zwię­złe opi­sy i mode­le mecha­ni­zmów dzia­ła­nia orga­ni­za­cji oraz opi­sy tego jakie infor­ma­cje i jak mają być prze­twa­rza­ne z uwzględ­nie­niem tego, że część tych prac nadal będą wyko­ny­wa­li ludzie. Takie jak regu­ły gry w sza­chy: waż­ne są dwie stro­ny opi­su reguł gry a nie set­ki stron opi­sów przy­kła­do­wych par­tii. (Źródło: Warsztaty Analityczne ? Czyli Malowanie Trawy | | Jarosław Żeliński IT-Consulting)

Tak więc robi­my to tak, jak w innych dzie­dzi­nach inży­nie­rii: ana­li­zu­je­my, pro­jek­tu­je­my i zle­ca­my wyko­na­nie (imple­men­ta­cję).

Na zakończenie

Kim jest, człon­kiem któ­re­go zespo­łu jest (powi­nien być) pro­jek­tant? Przewrotnie odpo­wiem, że prak­ty­ka poka­zu­je, że – z powo­du ryzy­ka pro­jek­to­we­go – wyko­naw­ca nie powi­nien sam sobie sta­wiać wyma­gań. To dla­te­go zło­żo­ne i ryzy­kow­ne pro­jek­ty mają wydzie­lo­ną rolę ana­li­ty­ka pro­jek­tan­ta, nie jest to czło­nek zespo­łu biz­ne­su ani deve­lo­pe­ra bo obie te stro­ny mają sprzecz­ne inte­re­sy (zakres i koszt). W bran­ży budow­la­nej jest to Biuro Projektowe (tu archi­tekt), trze­ci nie­za­leż­na rola, poza inwe­sto­rem i wyko­naw­cą (z uwa­gi na ryzy­ko, pra­wo budow­la­ne zabra­nia łącze­nia jakiej­kol­wiek z tych trzech ról). W meto­dy­kach takich jak SCRUM, jest to Product Owner, i z powyż­sze­go powo­du nie jest dobrze gdy jest to ​„czło­wiek developera”.

Dane są nieważne bo liczy się przede wszystkim mechanizm działania

Dodaj komentarz

Tym prze­wrot­nym tytu­łem chcę dziś zwró­cić uwa­gę na dwa waż­ne i bar­dzo pomoc­ne wzor­ce ana­li­tycz­ne (sło­wo ana­li­tycz­ne ode mnie, w książ­kach na temat wzor­ców bar­dzo rzad­ko uży­wa­na jest nazwa ​„wzor­ce ana­li­tycz­ne”) opi­sa­ne w książ­ce M.Fowlera. Wzorcami ana­li­tycz­ny­mi nazy­wam te wzor­ce pro­jek­to­we, któ­re poma­ga­ją w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu (biz­ne­so­wy model obiektowy).

MFowlerWzorceProjektowePolecam oczy­wi­ście lek­tu­rę całej książ­ki Martina Fowlera Architektura Systemów Zarządzania Przedsiębiorstwem Wzorce Projektowe.[1] Opisuje on w niej wła­snie wzor­ce pro­jek­to­we bar­dzo przy­dat­ne już na eta­pie pro­jek­to­wa­nia. Fowler nie uży­wa poję­cia ​„wzor­ca ana­li­tycz­ne­go” ale książ­ka jest podzie­lo­na na obsza­ry zasto­so­wa­nia wzor­ców, wśród nich znaj­dzie­cie więc wzor­ce logi­ki dzie­dzi­ny, wzor­ce pre­zen­ta­cji inter­ne­to­wych czy omó­wio­ne tu wzor­ce dys­try­bu­cji a tak­że bar­dzo przy­dat­ne wzor­ce okre­ślo­ne jako ​„pod­sta­wo­we”.

Poza wzor­ca­mi typo­wy­mi dla sys­te­mów obiek­to­wych w ogó­le, war­to zwró­cić uwa­gę na dwa. Opiszę krót­ko dwa bar­dzo przy­dat­ne na eta­pie ana­li­zy wzor­ce pro­jek­to­we (odno­śni­ki do stro­ny M.Fowlera): Transfer Object oraz Value Object.

Przykład użycia Value Object i Transfer Object

Na eta­pie ana­li­zy pro­ble­mu (ana­li­zy i mode­lo­wa­niu dzie­dzi­ny sys­te­mu) powin­no nas inte­re­so­wać przede wszyst­kim co i po co się dzie­je. Wielu ana­li­ty­ków o rodo­wo­dzie pro­gra­mi­stycz­nym zaczy­na pra­cę od pytań w rodza­ju ​„ile nazwi­sko ma zna­ków, czy mogą to być tyl­ko lite­ry czy coś jesz­cze”, itd. Jest to moim zda­niem kom­plet­ne nie­po­ro­zu­mie­nie. Zabieranie się za opra­co­wa­nie mode­lu od tej stro­ny (mode­lo­wa­nie danych) cał­ko­wi­cie przy­ćmi roz­wią­zy­wa­ny pro­blem. Np. sta­ra­jąc się zro­zu­mieć sys­tem sprze­da­ży bile­tów na samo­lot istot­ne jest na począt­ku nie to, ile zna­ków może mieć nazwi­sko a to, że bar­dzo istot­na jest iden­ty­fi­ka­cja pasa­że­rów i miejsc jakie mają zająć w samo­lo­cie. To nie jest to samo, bo iden­ty­fi­ka­cja pasa­że­rów ma za cel kon­tro­lę, kogo wpusz­cza­my na pokład samo­lo­tu, a nazwi­sko to jed­na z cech pasa­że­ra i na eta­pie ana­li­zy nie nale­ży zakła­dać, że to jedy­ny i naj­lep­szy spo­sób na to roz­róż­nie­nie. Brzmi jak here­zja? Zapewne, bo ​„więk­szość” ana­li­ty­ków zaczy­na wła­śnie od bada­nia np. nazwiska.

A kie­dy zając się nazwi­skiem? Dopiero wte­dy gdy zro­zu­mie­my pro­blem i opra­cu­je­my sys­te­mo­we jego roz­wią­za­nie. Po pierw­sze dla­te­go, że na począt­ku nie mamy wie­dzy (za wcze­śnie na taką decy­zję) by usta­lić na jakich kon­kret­nie danych będzie opie­ra­ła się iden­ty­fi­ka­cja pasa­że­rów (a nuż poja­wi się [[bio­me­tria]]), po dru­gie nie­po­trzeb­nie skom­pli­ku­je­my doku­men­ta­cję zamu­la­jąc ją od same­go począt­ku dużą ilo­ścią zbęd­nych ​„atry­bu­tów”.

Druga istot­na rzecz, to komu­ni­ka­cja. Wiemy, że fir­ma sprze­da­ją­ca bile­ty lot­ni­cze ope­ru­je róż­ny­mi dany­mi (lokal­ny model biz­ne­so­wy tej fir­my) na temat rezer­wo­wa­nych bile­tów. Wiemy, że te dane – o sprze­da­nych bile­tach – muszą być prze­ka­za­ne linii lot­ni­czej, ta zaś wcze­śniej musi jakoś prze­ka­zać infor­ma­cje o tym, na jakie loty i jakie bile­ty oferuje.

Co cie­ka­we, dosko­na­le to pasu­je to opi­sów wyko­ny­wa­nych przez zama­wia­ją­ce­go (albo jak kto woli user sto­ry). Normalny czło­wiek raczej powie nam, że ​„zapi­su­je dane pasa­że­ra”, ale raczej nie powie nam, że ​„reje­stru­je 25 zna­ków nazwi­ska, 20 zna­ków imie­nia i cza­sem 20 zna­ków dru­gie­go imie­nia.….”. Ten sam czło­wiek powie następ­nie, że prze­ka­zu­je dane o sprze­da­nych bile­tach do odpo­wied­nich linii lot­ni­czych a nie, że ​„doko­nu­je trans­fe­ru kolek­cji danych zawierających.….”.

Analiza i projektowanie

Na bazie wywia­dów, doku­men­tów itp. sta­ra­my się zro­zu­mieć ​„co jest gra­ne”, jak ten sys­tem funk­cjo­nu­je. Powstaje np. taki dia­gram. Tu zakła­dam już, że mode­lu­je­my sys­tem sprze­da­ży bile­tów, ale sys­tem ozna­cza ​„wszyst­ko to, co bie­rze w tym udział” a nie ​„kon­kret­ne oprogramowanie”:

Transfer biletów do linii lotniczej

Mamy model cze­goś co ma się wyda­rzyć. Na tym eta­pie kom­plet­nie nie ma sen­su zaj­mo­wa­nie się tym ile zna­ków ma nazwi­sko. To może się zmie­nić w toku ana­li­zy a nawet imple­men­ta­cji, ale nie powin­na ulec zmia­nie logi­ka tej operacji.

Jak już opa­nu­je­my logi­kę (zro­zu­mie­my co i jak ma dzia­łać i zapro­jek­tu­je­my jak to zre­ali­zo­wać) zabie­ra­my się za szcze­gó­ły. Model dzie­dzi­ny (frag­ment):

Model dziedziny

Jak widać, np. danePasażera jako zawar­tość to daneOsoby a nie ​„pola i typy danych”. Czym są DaneOsoby znaj­dzie­my tu:

ValueObject

Zamiast pro­stych typów danych (np. zna­ko­we) sto­su­je­my obiekt jako typ danych. To zna­ko­mi­cie uła­twia póź­niej­sze roz­sze­rze­nia i zmia­ny (nie musi­my nic zmie­niać w mode­lu dzie­dzi­ny by np. dodać dru­gie imię do danych oso­by, mody­fi­ku­je­my w jed­nym miej­scu jedy­nie dekla­ra­cję kla­sy DaneOsoby).

Wywołanie ope­ra­cji podajDaneBiletu zwra­ca obiekt DaneBiletuLitniczego (lub agre­gat zawie­ra­ją­cy wszyst­kie bilety):

Transfer ObjectNie jest to ten sam obiekt co wcze­śniej, ValueObject to typ danych, Transfer Object to seria­li­za­cja, któ­rej celem jest jedy­nie prze­nie­sie­nie w moż­li­wie naj­prost­szy do odczy­ta­nia spo­sób okre­ślo­nych infor­ma­cji (oba te obiek­ty nie mają jed­nak toż­sa­mo­ści). Nie nale­ży tych wzor­ców mylić ani utoż­sa­miać, gdyż Value Object to ​„typ danych” zaś Transfer Object to jedy­nie para­metr wywo­łań, Value Object powi­nien mieć ope­ra­cje sparw­dza­ja­ce jego popraw­ność (wali­da­cja), Transfer Object słu­ży wyłącz­nie do prze­ka­zy­wa­nia infor­ma­cji jako para­metr wywo­łań i odpo­wie­dzi (w pew­nym sen­sie defi­niu­je pro­to­kół wymia­ny danych).

Korzyści ze sto­so­wa­nia tych wzor­ców to mię­dzy innymi:

  1. szcze­gó­ły danych odkła­da­my na koniec pro­jek­tu co jest bez­piecz­ne (nie musi­my mody­fi­ko­wać pro­jek­tu w mia­rę postę­pu pozy­ski­wa­nia wie­dzy o szczegółach),
  2. zmia­na tych szcze­gó­łów nie spo­wo­du­je potrze­by zmia­ny szkie­le­tu mode­lu dziedziny,
  3. może­my pro­wa­dzić spo­koj­ną upo­rząd­ko­wa­ną ana­li­zę ​„top-down” (od ogó­łu do szczegółu),
  4. może­my się umó­wić z deve­lo­pe­rem, że jako ana­li­ty­cy nie będzie­my wni­ka­li w szcze­gó­ły danych, nadal może­my ope­ro­wać kla­sa­mi ValueObject i TransferObject (kla­sy te będą w począt­ko­wej fazie pro­jek­tu bez atrybutów),
  5. mimo to może­my umie­ścić w kla­sach ValueObject warun­ki wali­da­cji (ope­ra­cje klas, któ­rych tu nie poka­zy­wa­łem) i do tego one mię­dzy inny­mi słu­żą (to się nazy­wa okre­śla­nie wyma­gań poprzez testy czy­li TDD),
  6. już na samym począt­ku może­my uzgod­nić postać danych wymie­nia­nych na inter­fej­sach (np. zdal­na komu­ni­ka­cja) i korzy­stać z tej umowy.

Tak zapro­jek­to­wa­ny sys­tem speł­nia tak­że jed­ną z klu­czo­wych zasad pro­jek­to­wa­nia obiek­to­we­go: ​„sys­tem jest zamknię­ty na zmia­ny i otwar­ty na rozszerzenia”.

Na zakończenie

Często sły­szę, że to trud­ne i pra­co­chłon­ne (dodat­ko­we kla­sy w mode­lu), nie­ste­ty zbyt pro­sty pro­jekt potra­fi być kosz­tow­niej­szy w roz­bu­do­wie w porów­na­niu z pier­wot­nym wytwo­rze­niem, dla­te­go jak klient w ramach wyma­gań wpi­su­je (a wpi­su­je coraz czę­ściej): sys­tem ma umoż­li­wiać łatwe roz­sze­rze­nia funk­cjo­nal­no­ści, to nale­ży go tak pro­jek­to­wać, w prze­ciw­nym wypad­ku wyma­ga­nie to nie jest spełnione…

Druga uwa­ga: czę­sto sami klien­ci zabi­ja­ją swo­je pro­jek­ty żąda­jąc na samym począt­ku udo­ku­men­to­wa­nia wszyst­kich szcze­gó­łów jakie im do gło­wy przyj­dą nie potra­fiąc jed­no­cze­śnie opi­sać mecha­ni­zmu dzia­ła­nia ich orga­ni­za­cji (lub nowe­go pomy­słu). To nie­ste­ty czę­sto spo­ty­ka­ne zja­wi­sko, z któ­rym moim zda­niem nale­ży wal­czyć. Paradoksalnie zło­żo­ność sys­te­mów biz­ne­so­wych tkwi w mecha­ni­zmie ich funk­cjo­no­wa­nia a nie w danych, któ­re zbie­ra­ją (któ­rych nie raz jest po pro­stu za dużo…).

Dane to fak­ty jakie chce­my znać, te fak­ty są kon­se­kwen­cją dzia­ła­nia a nie odwrotnie. 

Na ryn­ku w Polsce są jesz­cze mię­dzy inny­mi książ­ki o wzorcach:

Moim zda­niem jed­nak nie przy­dat­ne ana­li­ty­kom. Pierwsza to wzor­ce ​„tech­nicz­ne”, sto­so­wa­ne głów­nie z kom­po­nen­tach Controller i View (archi­tek­tu­ra MVC). Druga to w zasa­dzie doku­men­ta­cja [[J2EE]]. Tak więc obie raczej dla pro­gra­mi­stów i archi­tek­tów. Książkę Fowlera pole­cam ana­li­ty­kom i archi­tek­tom tak­że. Wszystkim pole­cam tak­że UML i Wzorce pro­jek­to­we Larmana.

(UWAGA! Pokazano pro­jekt poglą­do­wy, wyssa­ny z pal­ca, nie ujaw­ni­łem tre­ści żad­ne­go z moich real­nych projektów).

Footnotes
[1]M. Fowler, Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​a​r​c​h​i​t​e​k​t​u​r​a​-​s​y​s​t​e​m​o​w​-​z​a​r​z​a​d​z​a​n​i​a​-​p​r​z​e​d​s​i​e​b​i​o​r​s​t​w​e​m​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​m​a​r​t​i​n​-​f​o​w​l​e​r​,​s​z​a​b​k​o​.​htm, udo­stęp­nio­no 16 lipiec 2017.
[2]H. SA, J2EE. Wzorce pro­jek­to­we. Wydanie 2 [na:] ?helion​.pl?, http://​helion​.pl/​k​s​i​a​z​k​i​/​j​2​e​e​-​w​z​o​r​c​e​-​p​r​o​j​e​k​t​o​w​e​-​w​y​d​a​n​i​e​-​2​-​d​e​e​p​a​k​-​a​l​u​r​-​j​o​h​n​-​c​r​u​p​i​-​d​a​n​-​m​a​l​k​s​,​j​2​e​e​w​2​.​htm, udo­stęp­nio­no 16 lipiec 2017.

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

4 komentarze

Niedawno pro­wa­dzi­łem krót­ką ale cie­ka­wą dys­ku­sje na temat podej­ścia do ofe­ro­wa­nia opro­gra­mo­wa­nia ERP, wdro­żeń, ich doku­men­to­wa­nia i zapi­sy­wa­nia wyma­gań. Osoba, z któ­rą dys­ku­to­wa­łem to były kon­sul­tant dostaw­cy opro­gra­mo­wa­nia ERP świa­to­we­go lide­ra w tej bran­ży. Rozmowa potwier­dzi­ła jed­ną rzecz: celem dostaw­cy goto­we­go sys­te­mu ERP jest wdro­żyć go bez żad­nych mody­fi­ka­cji bo (jej kosz­ty) zja­da­ją mar­żę dostaw­cy. Celem kupu­ją­ce­go opro­gra­mo­wa­nie ERP, jest wspar­cie swo­ich pro­ce­sów biz­ne­so­wych a nie kopia cudzych. To dwa sprzecz­ne inte­re­sy. Silna fir­ma wymu­si na dostaw­cy ERP zmia­ny, sła­ba nie raz pod­da­je się wie­rząc tezom dostaw­cy, że nowy sys­tem upo­rząd­ku­je stan ich orga­ni­za­cji i da prze­wa­gę nad kon­ku­ren­cją. Kto tu ma rację?

Drugie pyta­nie: Po co wyko­rzy­sty­wać np. nota­cję for­mal­ną UML czy BPMN przy wdro­że­niach goto­we­go opro­gra­mo­wa­nia? Po pierw­sze po to by dostaw­ca mógł spraw­dzić czy opro­gra­mo­wa­nie, któ­re ofe­ru­je prze­twa­rza takie dane i tak jak chce tego kupu­ją­cy. Po dru­gie jeże­li tyl­ko nale­ży dodać bra­ku­ją­ce funk­cjo­nal­no­ści to trze­ba je naj­pierw zapro­jek­to­wać a potem zaim­ple­men­to­wać. Niestety obser­wu­je, że to wła­śnie dostaw­cy goto­we­go opro­gra­mo­wa­nia łamią wszel­kie regu­ły tego pro­ce­su: pomi­ja­ją etap pro­jek­to­wa­nia nowych ele­men­tów sys­te­mu, czę­sto pra­cu­ją ?na żywioł? ? wpa­da ana­li­tyk dostaw­cy ERP i ?coś robi? od razu ?w sys­te­mie?. Potem jest tyl­ko lawi­na błędów?

Wróćmy więc do rozmowy:

[Konsultant zna­ne­go na ryn­ku mię­dzy­na­ro­do­wym sys­te­mu ERP. Wiele lat pra­co­wa­łam jako kon­sul­tant księ­go­wy przy wdro­że­niach sys­te­mów ERP, teraz pra­cu­je jako admi­ni­stra­tor modu­ło­wy. W obsza­rze moich zain­te­re­so­wań jest głów­nie pro­ce­so­we uje­cie przed­się­bior­stwa, ale rów­nież ana­li­zy przed­wro­że­nio­we oraz kon­cep­cje wdro­że­nio­we. Chciałabym Pana zapy­tać, jak w prak­ty­ce spraw­dza sie doku­men­ta­cja UML na potrze­by wdro­żeń? Z tego co zaob­ser­wo­wa­łam, a tak­że z roz­mów, dys­ku­sji doszłam do wnio­sku, że UML jest narzę­dziem pra­co­chłon­nym, cza­so­chłon­nym, za mało ​„prze­źro­czy­stym”.

[Jarosław Żeliński] UML to narzę­dzie for­mal­ne (nota­cja), wyma­ga więc pew­nej wie­dzy teo­re­tycz­nej (podob­nie jak pro­gra­mo­wa­nie z uży­ciem jakie­go­kol­wiek języ­ka pro­gra­mo­wa­nia). Pracochłonność? Model UML (np. dia­gram klas) jest (zależ­nie od sza­cun­ków) wie­lo­krot­nie mniej pra­co­chłon­ny w wyko­na­niu niż odpo­wia­da­ją­cy mu kod, prze­kła­da się to tak­że na testo­wa­nie kodu i oce­ny kosz­tu dane­go roz­wią­za­nia. Jednoznaczne opi­sa­nie np. for­ma­tu danych opi­so­wo (?pro­zą?) jest prak­tycz­nie nie­moż­li­we. Tabele są znacz­nie bar­dziej pra­co­chłon­ne niż dia­gram klas i maszy­ny sta­nów im odpowiadające.

[Konsultant] UML moim zda­niem nie wspo­ma­ga wdro­żeń, aby taka doku­men­ta­cja była war­to­ścio­wa musi być aktualizowana.

[JŻ] UML to nie jest narzę­dzie do wdro­żeń goto­wych sys­te­mów ERP, to jakieś nie­po­ro­zu­mie­nie, UML to narzę­dzie pro­jek­to­wa­nia opro­gra­mo­wa­nia, zaś w przy­pad­ku goto­wych ERP ma sens jedy­nie do mode­lo­wa­nia obiek­tów biz­ne­so­wych i inter­fej­sów na eta­pie spe­cy­fi­ko­wa­nia wyma­gań bo obiek­ty takie (np. fak­tu­ra, zle­ce­nie zała­dun­ku itp.) są prze­twa­rza­ne w sys­te­mach ERP (doku­men­ty itp.).

[Konsultant] Pan wie ile to zabie­ra czasu.

[JŻ] Znacznie mniej niż testo­wa­nie pro­to­ty­pów na żywym kodzie.

[Konsultant] Specjaliści z bran­ży źle sie wypo­wia­da­li o UML twier­dząc, że jest bar­dziej narzę­dziem aka­de­mic­kim, świet­nie uczą­ce filo­zo­fii pro­gra­mo­wa­nia, nato­miast zupeł­nie niepraktyczne.

[JŻ] Obawiam się, że nigdy nie korzy­sta­li z doku­men­ta­cji for­mal­nej, korzy­sta­li ze źle wyko­na­nej (w więk­szość jaką widu­ję) lub nie potra­fi­li sami jej wyko­nać w UML. Prawdopodobnie kry­ty­ko­wa­li coś cze­go nie uży­wa­li, jak prze­ka­zu­ję doku­men­ta­cje z uży­ciem UML to pro­gra­mi­ści klasz­czą z rado­ści, zaś na widok wyma­gań w posta­ci pro­zy od razu doda­ją 40% zapa­su na ryzyko …

[Konsultant] A Pan korzy­sta z UML’a. Jak do tego pod­cho­dzą klien­ci? Nie jest to pro­sta nota­cja i pew­nie nie do koń­ca zro­zu­mia­ła dla każ­de­go. Jakie są Pana spo­strze­że­nia w tym temacie?

[JŻ] UML to narzę­dzie ana­li­tycz­ne i pro­to­ty­po­we, klien­tom nie poka­zu­ję kodu pro­gra­mu i dia­gra­mów UML (po co??). Czy tłu­macz na chiń­ski daje swo­im klien­tom tekst tłu­ma­cze­nia do zatwier­dza­nia? Nie – daje go chiń­czy­kom do czy­ta­nia. Jest wie­le nie­po­ro­zu­mień wokół UML i BPMN. Krytykują go chy­ba tyl­ko Ci, któ­rzy nie zna­ją i nie potra­fią użyć. Podam taki przy­kład: wyma­ga­nia w posta­ci opi­su i dia­gra­mów UML są reali­zo­wa­ne przez pro­gra­mi­stów w zasa­dzie z bar­dzo małym ryzy­kiem, wyce­ny kosz­tów imple­men­ta­cji nie mylą się bar­dziej niż 10%, testo­wa­nie przy­pad­ków uży­cia na dia­gra­mach jest nawet 10 krot­nie tań­sze niż kodo­wa­nie i testo­wa­nie prototypów.

Typowe błę­dy jakie spotykam:

- złe mode­le (nie speł­nia­ją­ce zasad nota­cji, błęd­ne pro­jek­ty – w zasa­dzie nie­przy­dat­ne obraz­ki) fak­tycz­nie niko­mu nie poma­ga­ją (a wie­le jest nie­ste­ty złych, podob­nie mode­le pro­ce­sów, wie­le z nich to złe mode­le pozba­wio­ne zasad pragmatyki)

- sto­so­wa­nie UML do goto­wych sys­te­mów ERP jest nie­po­ro­zu­mie­niem za wyjąt­kiem doku­men­to­wa­nia danych oraz nowych funkcjonalności

- nie da się wyko­nać w posta­ci opi­su słow­ne­go sku­tecz­ne­go (jed­no­znacz­ne­go) opi­su dedy­ko­wa­ne­go sys­te­mu podob­nie (lub jakiej­kol­wiek dedy­ko­wa­nej czę­ści goto­we­go) jak nie da się tą meto­dą opi­sać pro­jek­tu biu­row­ca – robi sie rysun­ki tech­nicz­ne, któ­rych nie rozu­mie miesz­ka­niec tego biu­row­ca, ale te rysun­ki nie są dla nie­go, on dosta­je wizu­ali­za­cje (w inży­nie­rii opro­gra­mo­wa­nia matry­ce ekra­nów – mockupy).

Z moje­go doświad­cze­nia wszel­kie for­ma­li­zmy (UML, BPMN, inne) krytykują:

- ci któ­rzy ich nie rozumieją

- ci któ­rym prze­szka­dza­ją (zbyt jed­no­znacz­na doku­men­ta­cja pozwa­la ści­śle roz­li­czyć wyko­naw­cę, cze­go nie­któ­rzy nie chcą)

Dla przy­kła­du. Większość ludzi nie lubi geo­me­trii ale też nie potra­fią oni nicze­go nary­so­wać tyl­ko z pomo­cą cyr­kla i linij­ki, muszą mieć wzor­ni­ki do ryso­wa­nia figur geo­me­trycz­nych a na geo­me­trię narze­ka­ją, że trud­na i teo­re­tycz­na. Geometrie zna bar­dzo dobrze za każ­dy archi­tekt, musi. Niestety zawsze będą pro­jek­ty, w któ­rych mała i skoń­czo­na licz­ba goto­wych figur wzor­ni­ka nie wystar­cza i potrzeb­ne są inne… ktoś to musi zro­bić a nagi­na­nie wszyst­kie­go do kil­ku figur na wzor­ni­ku to zły pomysł…

Po dru­gie: nie­za­leż­nie od tego co wie ana­li­tyk piszą­cy wyma­ga­nia pro­zą, struk­tu­ra pro­gra­mu jest struk­tu­ra for­mal­ną i kom­pi­la­tor jest bez­względ­nym sędzią, podob­nie jak potem przy­szły użyt­kow­nik. To cze­go nie zwe­ry­fi­ko­wa­no na eta­pie pro­jek­to­wa­nia i tak trze­ba zro­bić na eta­pie kodo­wa­nia, tyl­ko tu jest to o wie­le droż­sze w przy­pad­ku popeł­nie­nia błędów.

Niewątpliwie ana­li­za i pro­jek­to­wa­nie (UML to narzę­dzie doku­men­to­wa­nia pro­jek­tu i two­rze­nia mode­li do testów) są trud­ne ale to tak jak z mode­la­mi samo­lo­tów w tune­lu aero­dy­na­micz­nym: nikt przy zdro­wych zmy­słach nie testu­je wszyst­kie­go na goto­wych samo­lo­tach tyl­ko na mode­lach bo to po pro­stu taniej (i bezpieczniej).

Zapewniam Panią, że tam gdzie pła­ci się ​„za dzie­ło” sta­ła kwo­tę coraz czę­ściej mode­lu­je się i pro­jek­tu­je na papie­rze np. w UML, a potem dopie­ro koduje.

[Konsultant] Do tego miej­sca wszyst­ko jest dla mnie pięk­ne, ale zna­jąc życie, resz­ta już nie jest taka pięk­na. Powstaje pro­to­typ i trze­ba go prze­te­sto­wać. Jakoś nie wyobra­żam sobie, aby nawet naj­bar­dziej dosko­na­le wyko­na­na doku­men­ta­cja UML pozwo­li­ła nam pomi­nąć ten etap. W 2004 roku przez oko­ło pół roku bra­łam udział we wdra­ża­niu sys­te­mu dedy­ko­wa­ne­go, pamię­tam etap testów, jak wie­le poja­wia­ło sie błę­dów, pamię­tam ogrom pra­cy jaki nagle poja­wił sie na tym eta­pie. Gdyby wów­czas mia­ło dojść do tego jesz­cze bie­żą­ca aktu­ali­za­cja doku­men­ta­cji UML to pew­nie ter­min zamknię­cia pro­jek­tu prze­su­nął­by sie dale­ko, daleko..

[JŻ]Mamy trzy pod­sta­wo­we eta­py two­rze­nia oprogramowania:

- ana­li­za wyma­gań, jej pro­duk­tem jest spe­cy­fi­ka­cja wymagań

- pro­jek­to­wa­nie

- imple­men­ta­cja

Testowanie doty­czy prak­tycz­nie każ­de­go etapu:

- spe­cy­fi­ka­cje wyma­gań testu­je­my na mapach pro­ce­sów i to jest pro­ste jeże­li mamy dobry model pro­ce­sów biz­ne­so­wych: każ­dy biz­ne­so­wy doku­ment powi­nien ​„przejść” przez model pro­ce­sów, na nim wska­zu­je­my miej­sca, w któ­rych ocze­ku­je­my inte­rak­cji z opro­gra­mo­wa­niem (sam dia­gram wska­że kontekst)

- pro­jekt (w szcze­gól­no­ści model dzie­dzi­ny) testu­je­my w ten spo­sób, że dla każ­de­go przy­pad­ku uży­cia wyko­nu­je­my model sekwen­cji: ta meto­dą prze­te­stu­je­my czy mamy wszyst­kie kla­sy i ich meto­dy czy­li prze­te­stu­je­my całą logi­kę systemu

- teraz ma miej­sce imple­men­ta­cja i tu testu­je­my kod każ­dej kla­sy (wewnątrz klas lub meto­dą testo­wa­nia inter­fej­sów, zale­ży od przy­ję­tej meto­dy, pole­cam poczy­ta­nie o TDD), bo one same z sie­bie, kla­sy i ich logi­ka prze­te­sto­wa­na na eta­pie pro­jek­to­wa­nia, są OK a pro­jekt jest spój­ny bo prze­szedł testy logi­ki na modelach.

I lite­ra­tu­ra i pro­gra­mi­ści potwier­dza­ją, że wykry­cie błę­du w pro­jek­cie jest co naj­mniej o rząd (albo nawet dwa, jak twier­dzą nie­któ­rzy) wiel­ko­ści tań­sze do popra­wie­nia niż błę­dy wykry­te w kodzie. Dotyczy to tak­że wpro­wa­dza­nia zmian.

[Konsultant] Aby Pan mnie źle nie zro­zu­miał, nie kwe­stio­nu­je korzy­sta­nia z UML’a, raczej w kon­tek­ście swo­ich doświad­czeń nie spo­tka­łam sie z wiel­ka apro­ba­tą u prak­ty­ków tego narzę­dzia. Dla mnie za bar­dzo ​„chce być boha­te­rem” w tej sztu­ce jakim jest wdro­że­nie. Za bar­dzo absor­bu­je w pro­ce­sie implementacji.

[JŻ] Podtrzymuje, że na UML (a kon­kret­nie pro­jek­to­wa­nie przed kodo­wa­niem) narze­ka­ją Ci któ­rzy pro­gra­mu­ją ​„na żywioł”, ana­lo­gie do pro­ce­su w budow­nic­twie są moim zda­niem jak naj­bar­dziej na miejscu.

[Konsultant] Mogę się mylić. Pan jest pierw­szym prak­ty­kiem jakie­go pozna­łam, któ­ry korzy­sta z UML’a i twier­dzi, że jest to dobre podej­ście, dla­te­go zapy­ta­łam Pana jak to wyglą­da w życiu.

[JŻ] W życiu jest tak, że moimi klien­ta­mi są głow­nie ​„fir­my po przej­ściach”, te któ­re doświad­czy­ły wdro­żeń bez eta­pu pro­jek­to­wa­nia. Ostatnio coraz czę­ściej kon­trak­ty zwią­za­ne z opro­gra­mo­wa­niem są ​„fixed pri­ce” (sta­łe zakres pro­jek­tu, koszt i ter­min reali­za­cji) i nie opła­ci się wyko­naw­cy ​„kodo­wać i testo­wać w nie­skoń­czo­ność”, kodo­wa­nie bez pro­jek­tu jest w zasa­dzie nie­prze­wi­dy­wal­nym pro­ce­sem (dokład­nie tak jak zło­żo­na budo­wa bez pro­jek­tu). Po dru­gie znam innych ludzi uży­wa­ją­cych UML, są to naj­czę­ściej ludzie zwią­za­ni z dobry­mi pro­gra­mi­sta­mi .NET, JAVA (J2EE) a tak­że pro­jek­tan­ta­mi baz danych, korzy­sta­ją­cy z wzor­ców pro­jek­to­wych i gene­ral­nie obiek­to­wych metod two­rze­nia opro­gra­mo­wa­nia. Praktycznie każ­da fir­ma korzy­sta­ją­ca z meto­dy­ki RUP (lub lżej­szej ICONIX) uży­wa UML w jakiejś posta­ci. W przy­pad­ku goto­wych sys­te­mów ERP jest to (UML) dosko­na­łe wręcz narzę­dzie do opi­sa­nia tego jakie dane o doku­men­tach nale­ży prze­twa­rzać i jak je przetwarzać.

[Konsultant] Ale tak sobie myślę, że Pan dostar­cza doku­men­ta­cje UML pro­gra­mi­stom, oni się cie­szą bo maja kawal robo­ty juz zro­bio­nej, ale czy póź­niej po zro­bie­niu pro­to­ty­pu ta doku­men­ta­cja jest dalej uak­tu­al­nia­na? Jeśli nie, to jej żywot jest skoń­czo­ny, wła­śnie ten etap powsta­wa­nia sys­te­mu jest dla mnie momen­tem, gdy zasta­na­wiam się nad sen­sem two­rze­nia pra­co­chłon­nej doku­men­ta­cji w nota­cji UML, ale mogę sie mylić.

[JŻ] Po pierw­sze dobry prze­te­sto­wa­ny pro­jekt nie jest zmie­nia­ny pod­czas imple­men­ta­cji 🙂 bo taka jest jego rola (jak dosta­nie Pani dobry pro­jekt archi­tek­to­nicz­ny dom­ku, to domek jak powsta­nie jest taki jak pro­jekt i nie ma co uak­tu­al­niać), waż­ne by utrzy­mać szcze­gó­ło­wość pro­jek­tu na wła­ści­wym pozio­mie, nie powi­nien wykra­czać zbyt­nio poza samą logi­kę dzia­ła­nia. Moim zda­niem wie­le pro­jek­tów UML jest prze­sad­nie szcze­gó­ło­wych a w wie­lu miej­scach są zbyt ogólne.

[Konsultant] Jednak chcia­ła­bym wró­cić do goto­wych sys­te­mów ERP bo taki­mi sie zaj­mu­je. Wracam do arty­ku­łu. Dlaczego glo­ry­fi­ku­je Pan przed­się­bior­stwo i jego potrze­by? Czytając Pana arty­kuł odno­szę wra­że­nie, że potrze­by przed­się­bior­stwa uzna­je Pan jako jedy­ne słusz­ne. A gdy­by tak było, to nie było­by szan­sy wdra­ża­nia goto­wych sys­te­mów, a trze­ba by dla każ­dej fir­my pisać dedy­ko­wa­ne opro­gra­mo­wa­nie. Bez sensu.

[JŻ] Osobiście uwa­żam, że zama­wia­ją­cy jest głów­nym źró­dłem wyma­gań ale pod tym poję­ciem rozu­miem spon­so­ra pro­jek­tu i to jego biz­ne­so­wy cel jest nad­rzęd­ny bo to on za swo­je pie­nią­dze reali­zu­je stra­te­gię swo­jej fir­my. Jestem gorą­cym zwo­len­ni­kiem tezy, że to mene­dżer (pre­zes, itp.) jest auto­rem celu biz­ne­so­we­go i to on sta­wia cele dostaw­com sys­te­mów ERP. Jeżeli jest ryzy­ko, że tu jest ​„pro­blem z zama­wia­ją­cym” (a nie raz bywa) to koniecz­ne nale­ży tu umie­ścić usłu­gę ​„doradz­twa biz­ne­so­we­go i stra­te­gicz­ne­go”, któ­ra da uzgod­nio­ne wyma­ga­nia i cele biznesowe.

Wdrażanie goto­we­go opro­gra­mo­wa­nia w dużych fir­mach bez mody­fi­ko­wa­nia go jest w prak­ty­ce bez sen­su bo fir­my się róż­nią. Na wdro­że­nie gotow­ca bez uwag może sobie pozwo­lić mała fir­ma kupu­ją­ca sys­tem fak­tu­ro­wa­nia z pudeł­ka za 1000zł, ale fir­ma mają­ca swo­je zwy­cza­je i stra­te­gię? Nie. W moich pro­jek­tach zawsze (po ewen­tu­al­nym upo­rząd­ko­wa­niu) sza­nu­ję wewnętrz­ne zwy­cza­je firm, powsta­je model pro­ce­so­wy całej fir­my (dość ogól­ny), na nim wydzie­la­ne są te obsza­ry, któ­re są kan­dy­da­tem na goto­wy ryn­ko­wy sys­tem ERP (z regu­ły obszar finan­sów i pro­duk­cja cza­sa­mi inne) a to co wyma­ga­ło­by zmian w danym sys­te­mie ERP kan­dy­du­je na dedy­ko­wa­ny pod­sys­tem. Proszę zwró­cić uwa­gę na to, że prak­tycz­nie każ­dy sys­tem ERP jest, pod­czas wdro­że­nia, para­me­try­zo­wa­ny a bar­dzo czę­sto tak­że mody­fi­ko­wa­ny. Jeżeli więc w ofer­cie widzę, że koszt mody­fi­ka­cji (dosto­so­wa­nia do potrzeb klien­tów, wpro­wa­dze­nie nowych funk­cjo­nal­no­ści) to np. 30% war­to­ści ofer­ty, to ten obszar roz­wa­żam jako mate­riał na dedy­ko­wa­ny pod­sys­tem. Potem nie raz oka­zu­je się, że dostaw­ca ERP doda bra­ku­ją­ce funk­cje za np. 200 tys., a dedy­ko­wa­ny sys­tem wraz z inte­gra­cją kosz­tu­je nie raz mniej niż 100 tys. (zazna­czam, że oba te warian­ty wyma­ga­ją zapro­jek­to­wa­nia i testo­wa­nia wiec to nie jest argu­ment prze­ciw­ko pro­jek­tom w np. w UML).

[Konsultant] Widzi Pan, pozna­jąc wie­le pol­skich przed­się­biorstw zda­łam sobie spra­wę, że w Polsce panu­je bar­dzo dziw­ny zwy­czaj (jeśli to moż­na nazwać zwy­cza­jem). Ktoś zdo­by­wa pie­nią­dze i posta­na­wia zało­żyć fir­mę. W okrze­płych wol­no­ryn­ko­wych pań­stwach (zachód) w takiej sytu­acji wła­ści­ciel finan­sów poszu­ku­je spe­cja­li­stów, mena­dże­rów. Przekazuje im pałecz­kę, czu­wa, dowia­du­je się ale jeśli się nie zna na biz­ne­sie, to sie nie wtrą­ca. U nas jest ina­czej: mam kasę, two­rze fir­mę, mia­nu­je się jej pre­ze­sem i wtrą­cam się wszę­dzie, wszyst­ko wiem naj­le­piej. Efektem jest stwo­rze­niem jakieś dziw­nej, indy­wi­du­al­nej stra­te­gii przed­się­bior­stwa. Nie raz sły­sza­łam z satys­fak­cją wypo­wia­da­ne sło­wa: Takich roz­wią­zań nie spo­tka­cie nigdzie! Ale to zupeł­nie nie o to cho­dzi. Nie chcę się roz­pi­sy­wać. Chciałabym jed­nak Panu powie­dzieć, że ofer­ta goto­we­go sys­te­mu, zawie­ra w sobie boga­tą bazę uwag, popra­wek zdo­by­tych w trak­cie wie­lu, wie­lu wdro­żeń. Moment wdro­że­nia syte­mu infor­ma­tycz­ne­go w przed­się­bior­stwie jest bar­dzo dobry, aby zre­wi­do­wać stra­te­gie i zało­że­nia biz­ne­su, jak jest reali­zo­wa­ny w fir­mie. Może war­to wła­śnie sko­rzy­stać z tego co ofe­ru­je sys­tem, a nie upie­rać sie, że moje roz­wią­za­nia są naj­lep­sze i tak musi być! Niestety czę­sto tak jest w praktyce.

Proponuje Pan zbyt ide­ali­stycz­ne roz­wią­za­nie. Sądzę że tutaj potrzeb­ny jest mądry kom­pro­mis mię­dzy tym co pro­po­nu­ją sys­te­my, a potrze­ba­mi firm i bra­ku­je mi jed­ne­go: ujednolicenia.

[JŻ] To jest to co róż­ni mnie od wie­lu dostaw­ców ERP, ale też nie ja jeden tak uwa­żam (pole­cam M.E.Porter – Strategia kon­ku­ren­cji, napi­sał tam, że fir­my kopiu­jąc tech­no­lo­gie od kogoś tym samym podej­mu­ją decy­zje że zre­zy­gno­wa­ły już z kon­ku­ro­wa­nia na ryn­ku). Źródłem prze­wa­gi ryn­ko­wej jest tyl­ko to co odróż­nia fir­mę od jej kon­ku­ren­tów. Studiuje tak­że lite­ra­tu­rę z zakre­su zarzą­dza­nia i mar­ke­tin­gu: nigdzie na świe­cie nie potwier­dza się teza, że sko­pio­wa­nie metod kon­ku­ren­ta daje cokol­wiek poza usta­wie­niem się za nim (nigdy przed). Tak więc jeże­li fir­ma decy­du­je się na roz­wój i chce sobie w tym pomóc wdra­ża­jąc nowe tech­no­lo­gie to wła­śnie po to to robi, by być jesz­cze trud­niej­szym do dogo­nie­nia. Ja tak­że bar­dzo czę­sto sły­szę ​„Takich roz­wią­zań nie spo­tka­cie nigdzie” i to jest głów­ny cel pro­jek­tu! Ujednolicenie firm to dla nich Walec Drogowy, któ­ry po nich prze­je­dzie i wyrów­na! Owszem trze­ba zwe­ry­fi­ko­wać i ewen­tu­al­nie zop­ty­ma­li­zo­wać orga­ni­za­cję fir­my (i po to się robi dobry model pro­ce­sów biz­ne­so­wych, by to prze­te­sto­wać i go ewen­tu­al­nie opty­ma­li­zo­wać) ale potem wła­śnie takie ​„dedy­ko­wa­ne roz­wią­za­nie” nale­ży zaim­ple­men­to­wać bo ta fir­ma naj­praw­do­po­dob­niej dzię­ki nie­mu wła­śnie jest lide­rem w swo­jej bran­ży (to nie jest przy­pa­dek, że nie­któ­re pro­ce­du­ry są tajem­ni­cą fir­my) i usu­nię­cie tego jej lokal­ne­go zwy­cza­ju może nawet zabić firmę.

[Konsultant] W tema­cie wdro­żeń panu­je taka róż­no­rod­ność na każ­dym eta­pie prac, że dopraw­dy trud­no się w tym poła­pać. Nie two­rzy­my wspól­nych plat­form, nie mamy ​„punk­tów wyj­ścia”, każ­de wdro­że­nie to pra­ca od począt­ku. Dla mnie to jest zupeł­nie nie tak.

[JŻ] A dla mnie jest to wła­śnie sens nowych tech­no­lo­gii IT i opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie. Polecam lite­ra­tu­rę o archi­tek­tu­rze kor­po­ra­cyj­nej, uka­za­ła się nie­daw­no książ­ka ​„Architektura kor­po­ra­cyj­na jako stra­te­gia”. W niej auto­rzy poka­zu­ją na przy­kła­dach wie­lu firm, lide­rów ryn­ko­wych, że wła­śnie kul­ty­wo­wa­nie wła­snych uni­kal­nych ​„struk­tur” dało im prze­wa­gę na ryn­ku i sukces.

Notatka: Polecam tak­że cie­ka­wy wpis na blo­gu Computerworld: ERP-owym pury­stom mówi­my sta­now­cze nie.