Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Niedawno w arty­ku­le o dość wyzy­wa­ją­cym tytu­le 😉 Gdzie są te cho­ler­ne szcze­gó­ły pisa­łem o zło­żo­no­ści wyma­gań i tym, gdzie ta zło­żo­ność jest (mogła by być, powin­na być doku­men­to­wa­na, jak kto woli). Tam sku­pi­łem się na takich szcze­gó­łach jak regu­ły biz­ne­so­we i zło­żo­ne typy danych, czy­li tym co potocz­nie (i nie do koń­ca słusz­nie) nazy­wa się wali­da­cja­mi” ([[wali­da­cja]]).

Drugim ele­men­tem nio­są­cym” szcze­gó­ły jest dia­log użyt­kow­ni­ka z apli­ka­cją czy­li ekra­ny”. Tu poja­wia się kolej­na por­cja wyma­gań, nie raz bar­dzo szcze­gó­ło­wych, zaciem­nia­ją­cych nie raz głów­ny sens two­rze­nia dane­go opro­gra­mo­wa­nia: sce­na­riu­sze pra­cy z ekra­nem (for­mat­ką ekra­no­wą itp.).

Jak już nie raz pisa­łem, ogól­na zasa­dą (dobrą prak­ty­ką) w inży­nie­rii jest abs­tra­ho­wa­nie oraz zarzą­dza­nie pozio­mem szcze­gó­ło­wo­ści każ­de­go eta­pu pra­cy na pro­jek­tem. Operowanie poję­cia­mi (ter­mi­na­mi) zamiast ich defi­ni­cja­mi, to abs­tra­ho­wa­nie od szcze­gó­łów czy­li ich her­me­ty­za­cja, np. Kontrahent” to nazwa pod­mio­tu, jego NIP, adres”.

Wymagania wobec apli­ka­cji zwią­za­ne z inte­rak­cją aktor-sys­tem, ich defi­nio­wa­nie i pro­jek­to­wa­nie reali­za­cji, nie nale­żą do łatwych eta­pów ana­li­zy i pro­jek­tu, są nie raz bar­dzo szcze­gó­ło­we. To powód dla któ­re­go war­to je tak­że her­me­ty­zo­wać”. Jak? Pomagają w tym dwie rze­czy: wyod­ręb­nie­nie pro­jek­to­wa­nia (doku­men­to­wa­nia) szcze­gó­łów inte­rak­cji jako etap pro­jek­to­wa­nia nazy­wa­ny [[User Experience]] (dalej UX) oraz uży­cie wzor­ca pro­jek­to­we­go MVVM-MVC.

Najpierw jed­nak wzor­ce, bo te dadzą nam kon­tekst i gra­ni­ce her­me­ty­za­cji. Wzorzec MVVM i korzy­ści pły­ną­ce z jego uży­cia, przy­stęp­nie opi­sa­no na stro­nie MSDN:

Przed omó­wie­niem wzor­ca, war­to zasta­no­wić się, po co utrud­niać sobie zada­nie poprzez wyko­rzy­sty­wa­nie MVVM, zamiast pisać apli­ka­cję w kla­sycz­ny spo­sób (za pomo­cą code-behind)? W koń­cu wdro­że­nie prak­tycz­nie każ­de­go wzor­ca pro­jek­to­we­go wyma­ga tro­chę więk­szych począt­ko­wych nakła­dów pracy.

Podejście Code-Behind (auto­no­mo­us view ? AV) ma poważ­ną wadę ? nie gwa­ran­tu­je ela­stycz­no­ści oraz testo­wal­no­ści. Podsumowując, wpro­wa­dze­nie wzor­ca umożliwia:

  1. nie­za­leż­ność logi­ki od spo­so­bu wyświe­tla­nia danych,
  2. nie­za­leż­ność kodu od tech­no­lo­gii, w któ­rej wyko­na­na jest war­stwa prezentacji,
  3. wyko­ny­wa­nie testów ? za pomo­cą MVVM czy MVP moż­li­we jest wyko­na­nie testów zauto­ma­ty­zo­wa­nych (np. jednostkowych),
  4. łatwą zamia­nę wido­ków (brak sztyw­nych powią­zań mię­dzy wido­kiem a logiką).

(Wprowadzenie do wzor­ca pro­jek­to­we­go Model-View-ViewModel na przy­kła­dzie apli­ka­cji WPF | MSDN (Polska).)

Z per­spek­ty­wy ana­li­zy i pro­jek­to­wa­nia ([[OOAD]]) naj­istot­niej­sze są pierw­sze dwa punk­ty, bo umoż­li­wia­ją her­me­ty­za­cję (oddzie­le­nie) logi­ki biz­ne­so­wej i pro­jek­tu opi­su­ją­ce­go inte­rak­cje aktor-sys­tem czy­li UX. Punkt czwar­ty daje speł­nie­nie jed­nej z zasad SOLID czy­li łatwość roz­sze­rze­nia bez potrze­by mody­fi­ka­cji”. Ta ostat­nia cecha to np. doda­wa­nie nowych inter­fej­sów użyt­kow­ni­ka do kolej­nych nowych urzą­dzeń (smart­fon, tablet, dedy­ko­wa­ne urzą­dze­nia i wyświe­tla­cze), bez potrze­by inge­ro­wa­nia w kod obsłu­gu­ją­cy już opro­gra­mo­wa­ne urządzenia.

Jak to wyglą­da z per­spek­ty­wy archi­tek­tu­ry apli­ka­cji i jej pro­jek­tan­ta? Poniżej model:

MVVM i MVC

Co tu mamy? Mamy MVVM i MVC na jed­nym dia­gra­mie. MVVM pole­ga na wsta­wie­niu pomię­dzy widok (View) a Model dodat­ko­we kom­po­nen­tu, któ­ry sta­no­wi wer­sję logi­ki biz­ne­so­wej zawie­ra­ją­cą ogra­ni­cze­nia wyświe­tla­cza” i dedy­ko­wa­ne (spe­cy­fiacz­ne) tyl­ko dla nie­go zacho­wa­nia (to tak­że pozwa­la uni­ka­nia bar­dzo złej prak­ty­ki jaką jest umiesz­cza­nie logi­ki biz­ne­so­wej w kom­po­nen­cie View). Innymi sło­wy, jeże­li jakieś zacho­wa­nia sys­te­mu są spe­cy­ficz­ne dla kon­kret­ne­go typu wyświe­tla­cza (ale może to być spe­cy­fi­ka akto­ra o czym dalej), logi­kę tę her­me­ty­zu­je­my w kom­po­nen­cie ViewModel.

Mając taką abs­trak­cję apli­ka­cji jak powy­żej, łatwo będzie osob­no opi­sać ją przy­pad­ka­mi uży­cia, uzna­jąc je za usłu­gi sys­te­mu (te świad­czy kom­po­nent Model) oraz osob­no szcze­gó­ło­wy­mi sce­na­riu­sza­mi UX zamknię­ty­mi w parze kom­po­nen­tów View-ViewModel. Oba te ele­men­ty pro­jek­tu – UX i Use Case, są więc ład­nie” odse­pa­ro­wa­ne, nie wpły­wa­ją na sie­bie nawza­jem i pozwa­la­ją na łatwą roz­bu­do­wę całe­go sys­te­mu, nie­wy­ma­ga­ją­cą mody­fi­ko­wa­nia już powsta­łe­go kodu (i dokumentacji).

Nawiąże jesz­cze do spe­cy­fi­ki akto­ra”. Bardzo czę­sto w sys­te­mach inter­ne­to­wych, mamy potrze­bę sepa­ra­cji użyt­kow­ni­ków z poza fir­my” (np. klien­ci skle­pu inter­ne­to­we­go, inter­fej­sy samo­ob­słu­gi dla klien­tów ser­wi­su itp.). Wiąże się to nie raz z bar­dzo zło­żo­ny­mi zasa­da­mi kon­tro­li dostę­pu do ele­men­tów mode­lu 9czyli dość głę­bo­ko w sys­te­mie). Potrafi to bar­dzo skom­pli­ko­wać cały pro­jekt kom­po­nen­tu Model, a nie raz potrze­by jego istot­nej prze­bu­do­wy. Można tego unik­nąć, her­me­ty­zu­jąc ten obszar. Bardzo czę­sto oso­ba (użyt­kow­nik, aktor sys­te­mu) z zewnątrz ma bar­dzo ogra­ni­czo­ne moż­li­wo­ści korzy­sta­nia z logi­ki całe­go sys­te­mu. Łatwiej jest zapro­jek­to­wać dedy­ko­wa­ny, rela­tyw­nie pro­sty kom­po­nent ViewModel i połą­czyć go z Modelem, niż mody­fi­ko­wać Model Dziedziny sys­te­mu by obsłu­gi­wał, nowe, nie raz bar­dzo wyra­fi­no­wa­ne, ogra­ni­cze­nia dostępu.

Tak więc przy­pad­ka­mi uży­cia opi­su­je­my abs­trak­cję jaką jest [[Model Dziedziny Systemu]]. Są one wte­dy pro­ste, zawie­ra­ją sce­na­riusz, któ­ry w skró­cie ma postać: aktor ini­cju­je usłu­gę, sys­tem pre­zen­tu­je for­mu­larz do wypeł­nie­nia, aktor wypeł­nia go i potwier­dza, sys­tem potwier­dza ode­bra­nie danych i poka­zu­je wynik swo­jej pra­cy (lub komu­ni­ka­ty o błę­dach). Tu sku­pia­my się na opi­sie tego jakie usłu­gi są wyma­ga­ne od sys­te­mu. Kolejny etap to kom­pli­ko­wa­nie” każ­de­go sce­na­riu­sza w posta­ci pro­jek­to­wa­nia, dla każ­de­go przy­pad­ku uży­cia, któ­ry tego wyma­ga, róż­ne­go rodza­ju wizar­dów lub wpro­wa­dza­my ogra­ni­cze­nia zwią­za­ne z upraw­nie­nia­mi użyt­kow­ni­ków. Ten etap to pra­ca pro­jek­tan­tów UX i gra­fi­ków, spe­cja­li­stów od ergo­no­mii itp.

Dom bez planów

CQRS czyli kto, co i jak zamawia i dostarcza

Poprzedni arty­kuł koń­czy­ły słowa:

Tak więc jest to moim zda­niem dro­ga do mode­lo­wa­nia wyma­gań meto­dą ?tak to ma dzia­łać? a nie tyl­ko ?tak to ma wyglą­dać?, bo to dru­gie jest przy­czy­ną wie­lu problemów?

Wielu deve­lo­pe­rów zacie­kle bro­ni się przed tezą, że wyma­ga­nia to tak­że ?żąda­na reali­za­cja logi­ki biz­ne­so­wej?, ocze­ku­ją wyłącz­nie zesta­wu wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych. Jest to moim zda­niem źró­dło dwóch ryzyk:

  • jeże­li zamó­wie­nie jest opi­sem czar­nej skrzyn­ki tak na praw­dę nie wie­my do dosta­nie­my jako jej realizację,
  • jeże­li auto­rem reali­za­cji jest dostaw­ca, pozo­sta­je mu nie­zby­wal­ne pra­wo do pro­jek­tu tej realizacji.

Dlatego war­to, jako wyma­ga­nie prze­ka­zać pro­jekt tak zwa­nej ?bia­łej skrzyn­ki?, bo zabez­pie­cza to nas przed powyż­szy­mi ryzy­ka­mi. (Wzorzec ana­li­tycz­ny Boundary Control Entity).

Czemu tak bro­nię tej tezy? Zarzuty deve­lo­pe­rów wobec mnie to: wymu­szasz imple­men­ta­cję a to rola pro­jek­tan­ta”. Jest to nie praw­da, bo pro­jek­ty wyma­gań zawie­ra­ją­ce wewnętrz­ną logi­kę to jesz­cze nie imple­men­ta­cja, ale na pew­no jest to ocze­ki­wa­nie kupu­ją­ce­go opro­gra­mo­wa­nie. Gdybym kupo­wał samo­chód nie chciał bym, by mi ktoś powie­dział, że wol­no mi powie­dzieć tyl­ko jak będę do nie­go wsia­dał, wysia­dał i po co, że będę zgod­nie z ogól­ny­mi zasa­da­mi naci­skał peda­ły i mani­pu­lo­wał drąż­kiem zmia­ny bie­gów. Nie! Mam pra­wo i ocho­tą okre­ślić typ sil­ni­ka, żądać ABS i wie­le innych rze­czy. Jeżeli ja nie znam się aż tak na samo­cho­dach popro­szę o pomoc kogoś kto się zna. Jest ryzy­ko? Jest, ale to ja o nim decy­du­ję a nie sprze­daw­ca samochodów!

Jeden z wielu powodów takiego podejścia

Przytłaczająca więk­szość deve­lo­pe­rów, z któ­ry­mi się spo­tka­łem, roz­wią­zu­je pro­blem wydaj­no­ści np. pra­cy z listą pro­duk­tów, podej­mu­jąc kom­pro­mis pomię­dzy szcze­gó­ło­wo­ścią i wier­no­ścią opi­su pro­duk­tu” a wydaj­no­ścią (czas odpo­wie­dzi sys­te­mu) np. pod­czas pre­zen­ta­cji (gene­ro­wa­nia) uprosz­czo­ne­go cen­ni­ka. Większość zna­nych mi deve­lo­pe­rów nie­ste­ty pre­zen­tu­je coś co nazy­wam struk­tu­ral­ny model pro­jek­to­wa­nia opro­gra­mo­wa­nia opar­ty na ane­micz­nym mode­lu dzie­dzi­ny”. Z regu­ły roz­wią­zu­ją oni opi­sa­ny wyżej pro­blem cen­ni­ka, uprasz­cza­jąc opis pro­duk­tu (psu­ją model!), umiesz­cza­ją uprosz­czo­ne dane o pro­duk­cie w mode­lu rela­cyj­nym wraz z resz­tą danych i wal­czą z opty­ma­li­za­cją zapy­tań do tej rela­cyj­nej bazy (uprasz­cza­nie i denormalizacja).

Nie raz pro­wa­dzi to do sytu­acji, w któ­rej opro­gra­mo­wa­nie jest szyb­kie i nieprzydatne”. 

< – jeże­li nie jesteś ana­li­ty­kiem przejdź na koniec artykułu – >

Wygląda to wte­dy np. tak (źr. Fowler CQRS):

Od pra­wej: inter­fejs użyt­kow­ni­ka, model dzie­dzi­ny, baza danych (pod­sys­tem utrwalania).

CQRS

Nie od dzi­siaj zna­ny jest wzo­rzec pro­jek­to­wy, któ­ry radzi sobie z tym pro­ble­mem. Nazywa się CQRS, i tak jest opi­sy­wa­ny przez guru” ana­li­zy i pro­jek­to­wa­nia :), Martina Fowlera:

CQRS stands for Command Query Responsibility Segregation. It’s a pat­tern that I first heard descri­bed by Greg Young. At its heart is a sim­ple notion that you can use a dif­fe­rent model to upda­te infor­ma­tion than the model you use to read infor­ma­tion. This sim­ple notion leads to some pro­fo­und con­se­qu­en­ces for the design of infor­ma­tion sys­tems. (źr. CQRS).

Idea tego pomy­słu na tym, by nie opty­ma­li­zo­wać wydaj­no­ści sys­te­mu meto­dą, nie raz zgni­łe­go, kom­pro­mi­su, a podejść do pro­ble­mu dzie­ląc go na dwa pro­ble­my: zgod­ność mode­lu z rze­czy­wi­sto­ścią i wydaj­ność całe­go sys­te­mu. Pierwszy pro­blem roz­wią­zu­je­my two­rząc wier­ny model struk­tu­ry opi­su­ją­cej pro­duk­ty, dru­gi pro­blem – wydaj­no­ści – roz­wią­zu­je­my two­rząc dru­gi uprosz­czo­ny model pro­duk­tów, do celów szyb­kiej reali­za­cji kil­ku waż­nych zapy­tań” (np. publi­ka­cja on line uprosz­czo­nej posta­ci cennika).

Powyższy dia­gram poka­zu­je: UI (inter­fejs użyt­kow­ni­ka), poka­zu­je menu zgod­ne z opi­sem z przy­pad­ków uży­cia (wyma­ga­nia funk­cjo­nal­ne). Model dzie­dzi­ny (część środ­ko­wa) poka­zu­je ocze­ki­wa­ne roz­wią­za­nie (takie­go żądam w wyma­ga­niach). Polega ono wła­śnie na zapro­jek­to­wa­niu w czę­ści dzie­dzi­no­wej odręb­ne­go mode­lu do zarzą­dza­nia poje­dyn­czy­mi pro­duk­ta­mi i odręb­ne­go do wydaj­ne­go zarzą­dza­nia ich kolek­cją. Owszem, model się nie­co skom­pli­ko­wał (jest nie­co kosz­tow­niej­szy w imple­men­ta­cji), ale jako zama­wia­ją­cy mam to cze­go potrze­bu­ję: wydaj­ny i uży­tecz­ny system.

< – jeże­li nie jesteś ana­li­ty­kiem tu zacznij czy­tać dalej – >

Opisując wyma­ga­nia wyłącz­nie jako czar­ną skrzyn­kę” nie wiem co dosta­nę. Większość deve­lo­pe­rów będzie dąży­ło do uprosz­cze­nia imple­men­ta­cji (ich koszt, nie raz brak wie­dzy) by zaspo­ko­ić na mini­mal­nym pozio­mie wyma­ga­nia opi­sa­ne przy­pad­ka­mi uży­cia. Nie raz klient sły­szy tu musi­my to upro­ścić bo tak się nie da”, a zama­wia­ją­cy, nie mając kom­pe­ten­cji by pole­mi­zo­wać z taką opi­nią, zga­dza się i dostar­czo­ny w efek­cie sys­tem sta­je się zgni­łym kom­pro­mi­sem opar­tym wła­śnie na czar­nej skrzyn­ce” jako spe­cy­fi­ka­cji zamó­wień: dosta­li­śmy dokład­nie to co zamó­wi­li­śmy ale zupeł­nie nie to cze­go napraw­dę potrzebujemy”. 

Tak więc,

nie ma zna­cze­nia fakt, że na pew­no są na ryn­ku deve­lo­pe­rzy zna­ją­cy pro­blem, któ­ry opi­sa­łem i sto­su­ją­cy opi­sa­ne tu roz­wią­za­nie takich pro­ble­mów. Jednak nawet cień ryzy­ka (a jest ono na praw­dę duże), że dosta­nie­my bubla, daje zama­wia­ją­ce­mu pra­wo do szcze­gó­ło­we­go defi­nio­wa­nia wyma­gań jako bia­łej skrzyn­ki”, bo dzię­ki temu zama­wia­ją­cy dosta­nie to cze­go potrze­bu­je a nie tyl­ko to co zamó­wił”.

Dla zain­te­re­so­wa­nych tak­że do pobra­nia książ­ka z MSDN:

The CQRS pat­tern and event sour­cing are not mere sim­pli­stic solu­tions to the pro­blems asso­cia­ted with lar­ge-sca­le, distri­bu­ted sys­tems. By pro­vi­ding you with both a wor­king appli­ca­tion and writ­ten guidan­ce, we expect you’ll be well pre­pa­red to embark on your own CQRS jour­ney. (za CQRS Journey).

co” system ma robić?">

Czy wymagania opisują tylko to co” system ma robić?

Bardzo czę­sto tak wła­śnie defi­niu­je się pro­dukt ana­li­zy wyma­gań: wyma­ga­nia funk­cjo­nal­ne opi­su­ją to co ma sys­tem robić. W dys­ku­sjach (ile mam ich za sobą :)) z pro­gra­mi­sta­mi prze­bi­ja się teza, że ana­li­tyk spe­cy­fi­ku­je to co” sys­tem ma robić, a oni już zała­twią spra­wę tego jak” ma to robić. W czym pro­blem? W tym, że lista funk­cjo­nal­no­ści to test roz­wią­za­nia (dostar­czo­ne­go opro­gra­mo­wa­nia) a nie wymagania!

Pytanie moje brzmi: A co to znaczy Jak”?

Czym jest owo jak”? Kodem pro­gra­mu, logi­ką na niskim pozio­mie, logi­ką na wyso­kim pozio­mie? Spójrzmy na taki pro­blem, wyma­ga­nie: klient wyma­ga by sys­tem pozwa­lał na wpro­wa­dza­nie tre­ści doku­men­tów, prze­ka­zy­wa­nie ich inne­mu pra­cow­ni­ko­wi wg. defi­nio­wa­nych reguł. Wiemy już co sys­tem ma robić. Tego typu sys­te­mów obie­gu doku­men­tów (tak się je czę­sto nazy­wa) są dzie­siąt­ki, róż­nią się od sie­bie nie­raz bar­dzo. Dlaczego?

Bo powyż­szy opis co” sys­tem ma robić to sta­now­czo za mało, tak na praw­dę nie defi­niu­je on nicze­go poza tym, w jaki spo­sób może zostać wyko­rzy­sty­wa­ny. Przypadek uży­cia jest dosłow­nie przy­pad­kiem uży­cia sys­te­mu”, ale przy­pad­ków uży­cia jest nie­skoń­cze­nie wie­le. Na ile spo­so­bów wyko­rzy­stu­je­cie posia­da­ne oprogramowanie?

Każdego dnia poja­wia się jakiś nowy pro­blem do roz­wią­za­nia i użyt­kow­nik pro­gra­mu będzie musiał się z nim zmie­rzyć. Skoro w toku ana­li­zy wska­za­no skoń­czo­ną licz­bę przy­pad­ków uży­cia, to czy daje to pra­wo by ktoś, np. pro­gra­mi­sta, nie zna­ją­cy ana­li­zo­wa­ne­go biz­ne­su, uzur­po­wał sobie pra­wo do pro­jek­to­wa­nia i kodo­wa­nia” tego Jak ten sys­tem będzie to robił? Do kodo­wa­nia na pew­no na pra­wo, ale czy do pro­jek­to­wa­nia tak­że? Czym jest tu to pro­jek­to­wa­nie i co jest pro­jek­to­wa­ne? Czym jest OOAD ([[Object Oriented Analysis and Design]], ang. ana­li­za i pro­jek­to­wa­nie obiektowe)?

Zacytuje po raz kolej­ny meta­fo­rę z książ­ki [[Martina Fowlera]]:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.” Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak ta meto­da i tak nie stwo­rzysz nawet dość dobrej symu­la­cji. Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre oprogramowanie.

Jak nie trud­no się domy­śleć ana­li­za wyma­gań nie może trwać w nie­skoń­czo­ność, powsta­nie mało takich opi­sów sce­na­riu­szy. Tak więc tra­dy­cyj­ne meto­dy, zapis wywia­dów, obser­wa­cje, ankie­ty, nie mają pra­wa się spraw­dzić bo w skoń­czo­nym cza­sie na ana­li­zę zawsze będzie ich za mało a i tak będą cha­otycz­ne (będzie to tyl­ko część tego co może się wyda­rzyć i nie wia­do­mo, któ­ra to część bo nie zna­my wszystkich).

Przypadki uży­cia sta­no­wią bar­dzo mier­ne przy­bli­że­nie rze­czy­wi­sto­ści. Oddanie pro­gra­mu do użyt­ku, reali­zu­ją­ce­go tyl­ko kon­kret­ne sce­na­riu­sze” i to w spo­sób obmy­ślo­ny” przez pro­gra­mi­stę, któ­ry nie potra­fi grać w sno­oke­ra a tyl­ko sły­szał od gra­cza jak się to robi, naj­pew­niej skoń­czy się zaba­wą w kolej­ne ite­ra­cje, pro­to­ty­py itp. Taki pro­gram będzie coraz lep­szy ale nadal nie dotknie nawet reali­zmu snookera.

Znacznie lep­szym wyj­ściem jest stwo­rze­nie mode­lu sto­łu i kul wraz z ich zacho­wa­niem się, reak­cja­mi na ude­rze­nia. Kto powi­nien to zro­bić? Ktoś kto dość dobrze gry­wa i rozu­mie sno­oke­ra, ale nie koniecz­nie mistrz tej gry, a tak­że zna­ją­cy jed­nak fizy­kę ciał sta­łych (tego raczej nie zna dobrze mistrz sno­oke­ra). Taki model to nie przy­pad­ki uży­cia (te są tyl­ko przy­kła­da­mi zasto­so­wa­nia) a model obiek­to­wy zawie­ra­ją­cy obiek­ty takie jak kula, kij itp.

Czy taki model stwo­rzy pro­gra­mi­sta na bazie roz­mów? Najczęściej nie! Co pro­gra­mi­sta zro­bi więc bar­dzo dobrze? Zapisze taki model w jakimś wybra­nym języ­ku pro­gra­mo­wa­nia ([[imple­men­ta­cja]]), zadba o to by moż­li­wa była gra setek użyt­kow­ni­ków, by moż­li­wa była 24 godzi­ny, sie­dem dni w tygo­dniu, wie­le, wie­le innych rze­czy ale nie model gry w snookera.

Co naj­waż­niej­sze: model taki nie może być żad­nym uprosz­cze­niem, gdyż ode­tnie to moż­li­wość jego roz­bu­do­wy (nowe wyma­ga­nia użyt­kow­ni­ka, a te poja­wią się na pew­no) w przyszłości.

Inny przy­kład. Jeżeli począt­ko­wo pro­jek­tu­je­my model pozwa­la­ją­cy kraw­co­wi pro­jek­to­wać i szyć spodnie, nie powin­ni­śmy pro­jek­to­wać zamknię­tej kon­struk­cji dwóch nóg, nale­ży stwo­rzyć model całe­go czło­wie­ka a w imple­men­ta­cji zawrzeć tyl­ko jego część od pasa w dół”. Będzie to pewien nad­miar ale jeże­li kie­dy­kol­wiek kra­wiec zechce posze­rzyć ofer­tę o mary­nar­ki do tych spodni, będzie to pro­ste roz­sze­rze­nie mode­lu a nie two­rze­nie go pra­wie od nowa. (tu kła­nia się DDD: ang. [[Domain Driven Design]] pole­ga­ją­cy na symu­lo­wa­niu w pro­jek­cie OOAD bytów świa­ta rzeczywistego).

Tak więc doku­ment wyma­gań to nie tyl­ko przy­pad­ki uży­cia. Te są raczej testem popraw­no­ści roz­wią­za­nia, czy model jest popraw­ny (przy­po­mi­nam, że przy­pad­ki uży­cia, poza ich sce­na­riu­sza­mi, zawie­ra­ją stan począt­ko­wy i stan koń­co­wy akcji użyt­kow­ni­ka). Dokument wyma­gań to model (tu [[model dzie­dzi­ny]]), któ­ry po zaim­ple­men­to­wa­niu, będzie się zacho­wy­wał tak jak tego ocze­ku­je­my a przy­pad­ki uży­cia będą jedy­nie dowo­dem na to, że jest on popraw­ny. O czym tu mowa?

iiba-modele-w-dokumencie-wymagan

Jeśli model przy­pad­ków uży­cia to model tak zwa­nej czar­nej skrzyn­ki, to model dzie­dzi­ny (bo tak się on nazy­wa) to tak zwa­na bia­ła skrzyn­ka. Tę bia­łą skrzyn­kę tak­że moż­na prze­te­sto­wać. Jak? Potraktować” ją przy­pad­ka­mi uży­cia (np. model kul i kija, kil­ka testo­wych ude­rzeń). Skoro mamy obiek­ty sys­te­mu (model, pro­jekt roz­wią­za­nia), któ­re reagu­ją na bodź­ce, to zna­czy, że moż­li­we jest poda­nie” sta­nu wej­ścio­we­go testo­wa­ne­go przy­pad­ku uży­cia mode­lu dzie­dzi­ny i spraw­dze­niu czy wytwo­rzy on ocze­ki­wa­ny stan koń­co­wy tegoż przypadku.

Model dziedziny to nie ten świat, o którym wielu myśli

Kolejna waż­na uwa­ga: w opro­gra­mo­wa­niu nie pro­jek­tu­je­my świa­ta rze­czy­wi­ste­go (no chy­ba, że to będzie gra), pro­jek­tu­je­my nasze narzę­dzia. Innymi sło­wy: w sys­te­mie nie mode­lu­je­my Dyrektora (on pozo­sta­nie żywy po wdro­że­niu), mode­lu­je­my kart­ki papie­ru na jakich zacho­wu­je­my o nim infor­ma­cję w real­nym świe­cie. Po co? By zamiast kar­tek użyć np. sys­te­mu kadro­wo-pła­co­we­go, by wyli­czył jego wyna­gro­dze­nie szyb­ciej i bez błę­dów. Zły model (przy­po­mi­nam, sys­tem biz­ne­so­wy to nie gra) zawie­ra kla­sę User, dobry model: UserInfo. Polecam książ­kę o meto­dy­ce ana­li­zy i mode­lo­wa­nia [[Toold&Materials design]].

Narzędzia pracy

Tu nie­ste­ty poja­wia się pew­na potrze­ba: narzę­dzie. Czym ono jest? Notacja obiek­to­wa UML. Po co to? Bo two­rze­nie i testo­wa­nie dia­gra­mów jest znacz­nie szyb­sze i tań­sze (zro­bi to ana­li­tyk pro­jek­tant) niż two­rze­nie wyko­ny­wal­ne­go kodu zdat­ne­go do testowania.

Dalej: opro­gra­mo­wa­nie CASE. Czy jaki­kol­wiek roz­sąd­ny foto­graf dzi­siaj pra­cu­je nad zdję­ciem cyfro­wym z pomo­cą pro­gra­mu PaintBrusz? Edytuje poszcze­gól­ne pik­se­le na pie­cho­tę”? Nie, korzy­sta­my z PhotoShopa, Gimpa, itp. Jak nazwać wiec ana­li­ty­ka, któ­ry mode­lu­je z pomo­cą takich narzę­dzi jak PowerPoint a nawet Visio? Są narzę­dzia, pakie­ty CASE, zwal­nia­ją­ce pro­jek­tan­ta z bene­dyk­tyń­skiej pra­cy nad dia­gra­ma­mi, może się sku­pić na tre­ści. Aha: UML to nie gene­ro­wa­nie pro­gra­mu, UML to ana­li­za i mode­lo­wa­nie, to narzę­dzie doku­men­to­wa­nia swo­ich pro­jek­tów. Dobry inży­nier uży­wa rysun­ku tech­nicz­ne­go, w inży­nie­rii opro­gra­mo­wa­nia jest to wła­sne UML. Jak ktoś uwa­ża, że UML jest bez sen­su sam cofa się o deka­dę w rozwoju.

Przykład

Na pew­nym forum poja­wi­ło sie takie zada­nie, weź­my sytu­ację biz­ne­so­wą (cytat):

Mamy por­tal dla klien­tów. Klientem jest fir­ma, któ­ra kupi­ła nasz pro­dukt. Każda fir­ma ma utwo­rzo­ne kil­ka kont użyt­kow­ni­ków. Na por­ta­lu pre­zen­to­wa­ne są nasze pro­duk­ty i jakieś dodat­ko­we eks­tra­sy dla nich.

Przypadek uży­cia:

Użytkownik [po zalo­go­wa­niu się] widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zakupiła.

Dla porząd­ku dia­gram Przypadków Użycia:

Jak widać, wyma­ga­nie funk­cjo­nal­ne nie za wie­le mówi, na tej pod­sta­wie może powstać nie­skoń­cze­nie wie­le roz­wią­zań. Prosty sce­na­riusz: użyt­kow­nik żąda ofer­ty, sys­tem wyświe­tla ofer­tę skła­da­ją­ca się z wcze­śniej kupio­nych pro­duk­tów. To tak­że nie poma­ga, to test tego czy sys­tem zro­bi to co chce­my. Czego nam potrze­ba? Potrzebujemy mode­lu wnę­trza, któ­ry zasy­mu­lu­je sys­tem”, infor­ma­cje któ­re posia­da­my, i odpo­wie ocze­ki­wa­ną ofer­tą”. Taki model to wła­śnie model dziedziny:

To nasze kule do sno­oke­ra”. Ale czy to dobry model? Czy przy­kła­do­wy bodziec (żąda­nie ofer­ty) da ocze­ki­wa­ny rezul­tat? Sprawdźmy to na modelu:

Co tu mamy? To symu­la­cja tego co zro­bił­by (powi­nien) przy­szły goto­wy pro­gram. Testowanie i pro­jek­to­wa­nie to pro­ces ite­ra­cyj­ny: jeże­li powyż­szy model (dia­gram sekwen­cji UML) nie da ocze­ki­wa­ne­go rezul­ta­tu (stan koń­co­wy przy­pad­ku uży­cia) należ go popra­wić. Po co takie zaba­wy? Zwróćcie uwa­gę ile obiek­tów jest na mode­lu dzie­dzi­ny, czy jeste­śmy w sta­nie to sobie wyobra­zić ze szcze­gó­ła­mi w gło­wie? Takich obiek­tów w dużym sys­te­mie będą dzie­siąt­ki! Okazji do pomył­ki, bra­ku­ją­cy obiekt, bra­ku­ją­ca infor­ma­cja itp. jest wiele.

Po takich testach (wery­fi­ka­cja roz­wią­za­nia pole­ga na potrak­to­wa­nie” mode­lu dzie­dzi­ny wybra­ny­mi lub wszyst­ki­mi przy­pad­ka­mi uży­cia) uzu­peł­ni­my wszel­kie ewen­tu­al­ne bra­ki mode­lu. Po co? By tych bra­ków nie odkry­wać na eta­pie kodo­wa­nia, bo to jest nawet 100 razy kosztowniejsze!

Ważna infor­ma­cja: powyż­sze dia­gra­my to za mało. Wywołanie ope­ra­cji kla­sy, w więk­szo­ści przy­pad­ków, wyma­ga poda­nia para­me­trów, odpo­wiedź sta­no­wi np. obiekt lub ich kolek­cja albo np. plik XML (lub inny struk­tu­ral­ny). Struktury tych obiek­tów opi­sy­wa­ne są na odręb­nych dia­gra­mach. Tak więc początkowe

Użytkownik [po zalo­go­wa­niu się] widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zakupiła.

poka­za­ne na powyż­szym dia­gra­mie sekwen­cji, pole­ga na tym, że GUI zażą­da od Logiki listę nazw pro­duk­tów sprze­da­nych fir­mie, do któ­rej jest przy­po­rząd­ko­wa­ny zalo­go­wa­ny użyt­kow­nik. Żądanie to, po spraw­dze­niu logi­ki praw dostę­pu itp., zosta­nie prze­ka­za­ne do repo­zy­to­rium Informacje, któ­re zwró­ci kolek­cję obiek­tów speł­nia­ją­cą powyż­szy waru­nek. Jedna waż­na rzecz: powyż­sze to nie przy­pa­dek uży­cia” a regu­ła biz­ne­so­wa: widzi tyl­ko takie pro­duk­ty, któ­re jego fir­ma kie­dyś zaku­pi­ła. Przypadkiem uży­cie jest raczej usłu­ga apli­ka­cji Zarządzanie histo­ria zakupów.

Mamy więc kon­cep­cje roz­wią­za­nia (tak zwa­ny model logicz­ny). Powyższe dia­gra­my są tu uprosz­czo­ne, wyma­ga­ły by na pew­no dopiesz­cze­nia ale ilu­stru­ją ideę obiek­to­wej ana­li­zy i pro­jek­to­wa­nia kon­cep­cji roz­wią­za­nia. Realne pro­jek­ty są oczy­wi­ście więk­sze ale nie zapo­mi­naj­my, że duże pro­jek­ty dzie­li się (powin­no) na mniej­sze (mikro­ser­wi­sy). Model dzie­dzi­ny dzie­li się na obsza­ry dzie­dzi­no­we, (modu­ły, pod­sys­te­my) by każ­dy z nich pozwa­lał na łatwe testo­wa­nie jak powy­żej. Po dru­gie doświad­czo­ny ana­li­tyk szyb­ko wychwy­ci, któ­re pod­sys­te­my moż­na kupić na ryn­ku (tak zwa­ne ang. COTS, Commercial of the Shelf), a któ­re nale­ży zapro­jek­to­wać do wyko­na­nia. Systemy zło­żo­ne pro­jek­tu­je się na pew­nym wyż­szym pozio­mie abs­trak­cji (meto­do­lo­gia top-down), ale sta­le jest to model i jego testo­wa­nie. Ale to tyl­ko (dla użyt­kow­ni­ka ) tak zwa­na logi­ka biznesowa.

Programiści!

Nikt Wam nie odbie­ra chle­ba, macie dużo pra­cy: po pierw­sze imple­men­ta­cja metod (algo­ryt­mów) poszcze­gól­nych obiek­tów (np. podaj nazwy pro­duk­tów, któ­re już raz kupio­no), macie zadbać o to: sys­tem ma być bez­piecz­ny, wydaj­ny, dzia­łać zdal­nie na tele­fo­nach komór­ko­wych, ma być bez­a­wa­ryj­ny itd. To wyma­ga­nia poza funk­cjo­nal­ne (lub w nie­któ­rych meto­dy­kach tak zwa­ne ogra­ni­cze­nia). Macie dzie­siąt­ki pro­ble­mów tech­nicz­nych do rozwiązania.

Ale pro­szę, nie uda­waj­cie, że zna­cie się na zarzą­dza­niu, mar­ke­tin­gu, biz­ne­sie, sprze­da­ży, ryn­ku, pro­duk­cji itp. bo to (poza pew­nie ist­nie­ją­cy­mi wyjąt­ka­mi) nie praw­da, a pro­jek­to­wa­nie na zasa­dzie wyda­je mi się że rozu­miem” to dro­ga do porażki.

Struktura wzorca MVC

Powyżej struk­tu­ra naj­czę­ściej uży­wa­ne­go, w meto­dach obiek­to­wych, wzor­ca pro­jek­to­we­go. Można uznać to za zało­że­nia pro­jek­to­we, tak wyglą­da każ­dy” sys­tem (uży­wa­ją­cych innych wzor­ców prze­pra­szam). Powyższy dia­gram pozwa­la jed­no­znacz­nie przy­po­rząd­ko­wać odpo­wie­dzial­ność za pro­jekt: ana­li­tyk pro­jek­tu­je war­stwę Model, pro­gra­mi­ści całą resz­tą. Przypadki uży­cia, per­spek­ty­wa obiek­tu User, tak­że znaj­dą się w doku­men­ta­cji wyma­gań. Co jesz­cze powin­na zawie­rać taka doku­men­ta­cja? Ewentualne ocze­ki­wa­nia użyt­kow­ni­ka do inter­fej­su użyt­kow­ni­ka (w koń­cu to zoba­czy, i tyl­ko to). wcze­śniej­sze dia­gra­my to model dzie­dzi­ny i jego testo­wa­nie. Daleki jestem od narzu­ca­nia wyko­naw­cy, w doku­men­cie wyma­gań, pozo­sta­łych ele­men­tów opro­gra­mo­wa­nia ale model biz­ne­so­wy to nie robo­ta dla programistów!

Taki pro­jekt jak powy­żej pozwa­la na dokład­ną wyce­nę, osza­co­wa­nie pra­co­chłon­no­ści. Mamy opis przed­mio­tu zamó­wie­nia”. Model dzie­dzi­ny opi­su­je kom­po­nent Model, wyma­ga­nia poza­func­kjo­nal­ne pozo­sta­łą resztę.

Proszę, nie wma­wiaj­cie swo­im klien­tem, że poza user sto­ry i przy­pad­ka­mi uży­cia nie ma innych metod opi­su wyma­gań, nie wma­wiaj­cie, że nie ma stan­dar­dów i że trze­ba pró­bo­wać” się sta­rać, bo to po pro­tu nie praw­da. To, że ktoś cze­goś nie widział (nawet przez lata swo­jej pra­cy) nie sta­no­wi żad­ne­go dowo­du na to, że to nie istnieje.

Tak więc spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych bez takich testów i bez mode­lu dzie­dzi­ny tak na praw­dę o niczym nie mówi. Czym to gro­zi? Tym, że zama­wia­ją­cy naj­czę­ściej dosta­nie to co chce (potra­fi) dostar­czyć dostaw­ca a nie to cze­go potrzebuje.

Jak to wygląda dla systemów ERP?

Jeśli z ana­li­zy wyj­dzie, że np. 3/4 wyma­gań mie­ści się w moż­li­wo­ściach goto­wych ryn­ko­wych sys­te­mów (owe COTS) to się wybie­ra goto­wy ERP (wybra­ne modu­ły) speł­nia­ją­cy opi­sa­ne wyma­ga­nia (tyl­ko przy­pad­ki uży­cia i model klu­czo­wych obiek­tów biz­ne­so­wych takich jak np. fak­tu­ra VAT). I to jest wła­ści­wa kolej­ność. Co będzie jeśli zacznie­my od wybo­ru goto­we­go sys­te­mu? Chyba nie muszę już odpowiadać…

Systemy ERP to zło­żo­ne , wie­lo­mo­du­ło­we pro­duk­ty. Czy jest sens spe­cy­fi­ko­wa­nie skoń­czo­nej licz­by ocze­ki­wa­nych funk­cjo­nal­no­ści (przy­pad­ków uży­cia) by wybrać taki sys­tem? Będzie ich nawet kil­ka tysię­cy! Nie! Ani tego nie zwe­ry­fi­ku­je­my ani nie spraw­dzi­my pod­czas odbio­ru sys­te­mu (powo­dze­nia w takich testach odbio­ro­wych). Więc jak?

System ERP moż­na wybrać na bazie pro­jek­tu, tu tyl­ko na nie­co wyż­szym pozio­mie abs­trak­cji. Analiza fir­my tak­że pole­ga tu na opra­co­wa­niu mode­li pro­ce­sów. Jednak w tym wypad­ku ich celem jest stwo­rze­nie raczej mode­lu filo­zo­fii dzia­ła­nia” fir­my a nie pro­jek­to­wa­nie sys­te­mu od zera. Założenie: sys­tem na ryn­ku ist­nie­je, nale­ży go jedy­nie wybrać z pośród wie­lu ist­nie­ją­cych. Do tego potrzeb­ny jest model dzie­dzi­ny i kon­cep­cja archi­tek­tu­ry a nie set­ki wyma­gań funkcjonalnych.

Najpierw dostaw­ca sys­te­mu ERP i wyko­na­na przez nie­go ana­li­za przed wdro­że­nio­wa czy może jed­nak naj­pierw ana­li­za wyma­gań? Zadam to samo pyta­nie ina­czej, coś z Państwa podwór­ka: naj­pierw ana­li­za miesz­ka­nia i pomysł na meblo­wa­nie a potem jaz­da po skle­pach i szu­ka­nie mebli, czy może naj­pierw daje­my sobie sprze­dać meble a potem wci­ska­my je w nasze poko­je (plus osła­wio­na ich kasto­mi­za­cja)? Państwo sami musza pod­jąć decy­zję, ryzy­ka opi­sa­łem. Powiem tyl­ko tyle: war­to zmie­rzyć dobrze miesz­ka­nie, opra­co­wać pomysł, kupić na ryn­ku to co pasu­je, a pozo­sta­łe zaka­mar­ki zle­cić dobre­mu sto­la­rzo­wi, któ­ry wpa­su­je meble i ład­nie połą­czy je z już kupionymi. 

A skąd brać te przypadki użycia?

Najgorsza meto­da, bo nie pod­da­ją­ca się testo­wa­niu (wery­fi­ka­cji), to: wywia­dy, ankie­ty, warsz­ta­ty i podob­ne meto­dy dekla­ra­tyw­ne. Dostaniemy set­ki nie­spój­nych wyma­gań, nie raz będą­cych efek­tem wewnętrz­nych wewnętrz­nych nego­cja­cji, roz­gry­wek (tak, nie­ste­ty). Powstanie nie­we­ry­fi­ko­wal­na lista na set­ki pozy­cji. Jak inaczej?

Analizujemy fir­mę, two­rzy­my jej model pro­ce­so­wy jak na dia­gra­mie powy­żej. Model pro­ce­sów testu­je­my z pomo­cą real­nych doku­men­tów. Po takich testach, wybie­ra­my na tym mode­lu te czyn­no­ści, któ­re uzna­my za nasze wyma­ga­nia. Praktyka poka­zu­je, że jest ich tak na praw­dę dzie­siąt­ki a nie set­ki (są to logicz­ne czyn­no­ści z ewen­tu­al­ny­mi warian­ta­mi). Nie może­my się tu pomy­lić bo mamy prze­te­sto­wa­ny model pro­ce­so­wy fir­my. Jednak ten model tak­że (podob­nie jak mode­le UML) musi pod­le­gać testom i for­ma­li­za­cji (naj­le­piej zasto­so­wać for­mal­ną, pozwa­la­ją­ca na testo­wa­nie, nota­cję, np. BPMN – powyż­szy dia­gram). Bez tego, model pro­ce­sów nie będzie lep­szy od opi­su słow­ne­go. Ale o tym już było 🙂 (i pew­nie jesz­cze będzie).

(wię­cej o przej­ściu z pro­ce­sów na przy­pad­ki uży­cia: trans­for­ma­cja mode­lu pro­ce­sów na model przy­pad­ków uży­cia)

Zamawiających nie stać na takie analizy jak powyżej.

Czyżby? Taka ana­li­za to ok. 20% budże­tu prac pro­gra­mi­stycz­nych i 50% cza­su pro­jek­tu. Bez niej jed­nak pro­jekt pły­nie w user sto­ry, pro­to­ty­py, odkry­wa­nie wyma­gań w trak­cie pro­jek­tu, ite­ra­cje (Agile?), ter­min jest prze­su­wa­ny kolej­ny raz. Klient pła­ci. Badania wyka­zu­ją (i dekla­ru­ją to tak­że wyko­naw­cy, czy­taj poprzed­nie moje posty z cyta­ta­mi, gorą­co pole­cam blo­gi pro­gra­mi­stów i ich opi­nie o use­rach oraz ana­li­ty­kach i sprze­daw­cach ich firm!), że w kon­se­kwen­cji kosz­tu­je to 200% pla­nu pier­wot­ne­go (typo­wy narzut dostaw­ców opro­gra­mo­wa­nia, patrz dia­gram poni­żej, bywa że narzu­ca­ją nawet 500% na nie­wie­dzę i niezrozumienie) !!!!!!

Powyższa meto­da pozwa­la by pro­jekt miał to co powi­nien mieć: dobrze okre­ślo­ny zakres pro­jek­tu (opis przed­mio­tu zamó­wie­nia) a na jego pod­sta­wie dobrze osza­co­wa­ny budżet (ren­tow­ność!) i ter­min wykonania.

Nikt tego nie rozumie czyli kto i co czyta: adresaci dokumentów

Często innym, poza budże­tem, argu­men­tem prze­ciw­ko takim ana­li­zom jest zarzut: Klient nie rozu­mie mode­li ani dia­gra­mów więc po co je robić”. A kto powie­dział, że Klient ma je czy­tać! Klient jest przede wszyst­kim źró­dłem wie­dzy o wła­snej fir­mie, wery­fi­ku­je model pro­ce­sów z pomo­cą ana­li­ty­ka, usta­la zakres pro­jek­tu, spraw­dza i potwier­dza biz­ne­so­wy opis swo­jej fir­my i jej potrze­by. Potem zatwier­dza ewen­tu­al­ne pro­to­ty­py ekranów.

Ten zarzut nie­ste­ty czę­sto sta­wia­ją tak­że nie­kom­pe­tent­ni dostaw­cy, nie potra­fią­cy nic inne­go poza eks­pe­ry­men­ta­mi, pro­to­ty­pa­mi i zja­da­niem budże­tu Klienta: im wię­cej tym lepiej…

Modele pro­ce­sów to narzę­dzie ana­li­ty­ka, mode­le UML tak­że ale te czy­ta wyko­naw­ca (jak wyko­naw­ca nie potra­fi czy­tać UML to on ma pro­blem, a nie ana­li­tyk czy klient.!). To dokład­nie tak jak z miesz­ka­niem: pro­jek­tant wnętrz słu­cha klien­ta i poka­zu­je mu efekt pra­cy: wizu­ali­za­cję. Potem opra­co­wu­je doku­men­ta­cje tech­nicz­ną dla sto­la­rza, rysun­ki tech­nicz­ne, nazwy mate­ria­łów. Tego klient fak­tycz­nie raczej nie rozu­mie ale nie dla nie­go są te doku­men­ty. Jednak dobry sto­larz to twór­czy inży­nier, potra­fią­cy wyko­nać pro­jekt i nie wci­ska klien­to­wi, tań­szych mate­ria­łów, nie uprasz­cza fine­zyj­nych zwień­czeń sza­fy bo po pro­tu psuje.

Jak wie­my sto­la­rze są róż­ni dla­te­go coraz czę­ściej pro­jek­tan­ci wpi­su­ją do swo­ich umów tak zwa­ny nad­zór autor­ski nad reali­za­cją. Ja tak­że tak robię.

Dla zain­te­re­so­wa­nych nie­co wię­cej na ten temat na stro­nach MSDN:

http://​msdn​.micro​soft​.com/​e​n​-​u​s​/​l​i​b​r​a​r​y​/​d​d​4​0​9​3​7​6​.​a​spx

IFS Open Information Architecture

Frameworks Introduction – czyli jak się psuje dobre ERP

Swego cza­su bra­łem udział w burz­li­wiej dys­ku­sji (zresz­tą nie­jed­nej) na temat sen­su prac ana­li­tycz­nych i pro­jek­to­wych przy oka­zji wdra­ża­nia sys­te­mów ERP, czy­li goto­we­go opro­gra­mo­wa­nia (prze­czy­taj arty­kuł). Większość dostaw­ców tego opro­gra­mo­wa­nia, z jaki­mi mie­wam kon­takt, uwa­ża, że ana­li­za owszem ale w celu opra­co­wa­nia kon­cep­cji wdro­że­nia, czy­li doku­men­tu mówią­ce­go jak dosto­so­wać sys­tem ERP do potrzeb klien­ta z naci­skiem na sło­wo kom­pro­mis. Pojawia się prę­dzej czy póź­niej świę­te sło­wo kasto­mi­za­cja, któ­re po pro­tu ozna­cza naj­czę­ściej prze­ra­bia­nie goto­we­go pro­duk­tu (nie raz bar­dzo dobre­go do momen­tu gdy się go nie popsu­je tymi prze­rób­ka­mi, prze­czy­taj i ten arty­kuł).

Niedawno pisa­łem, że

goto­we opro­gra­mo­wa­nie nale­ży zosta­wić nie­tknię­te (nie licząc okie­nek kon­fi­gu­ra­cji) a bra­ku­ją­ce funk­cjo­nal­no­ści opra­co­wać, zapro­jek­to­wać i zin­te­gro­wać.

Z regu­ły jak tyl­ko wypo­wiem tę kwe­stię, lecą na mnie gro­my ze stro­ny kon­sul­tan­tów dostaw­ców ERP. Jednak war­to te meto­dę sto­so­wać co potwier­dza­ją nie tyl­ko moje doświadczenia:

Eksperci pod­kre­śla­ją bowiem, że więk­szość kosz­tów gene­ro­wa­nych przez pro­jekt wdro­że­nio­wy nie ma nic wspól­ne­go z kosz­tem same­go opro­gra­mo­wa­nia. ?Średnio trzy czwar­te budże­tu pochła­nia­ją kosz­ty wdro­że­nia, mody­fi­ka­cji stan­dar­do­wej funk­cjo­nal­no­ści oraz moder­ni­za­cji sprzę­tu? ? czy­ta­my w rapor­cie Panorama Consulting Group. […] O sys­te­mach kla­sy ERP coraz czę­ściej mówi się, że są zbyt roz­le­głe, ocię­ża­łe i ogra­ni­cza­ją moż­li­wo­ści biz­ne­su, od któ­re­go wyma­ga się zwin­no­ści i ela­stycz­no­ści. Czy cza­sy takich sys­te­mów już prze­mi­ja­ją?? (źr. IDG, 2010r)

Stale śle­dzę to co się dzie­je na ryn­ku sys­te­mów IT wspo­ma­ga­ją­cych zarzą­dza­nie obser­wu­ję taki wła­snie kie­ru­nek rozwoju:

Systemy zin­te­gro­wa­ne ERP będą pew­ny­mi zesta­wa­mi goto­wych funk­cjo­nal­no­ści, zbu­do­wa­ny­mi w opar­ciu o szkie­le­ty opro­gra­mo­wa­nia zaś inte­gra­cja będzie bazo­wa­nia nie na współ­dzie­le­niu danych a na wymia­nie ich pomię­dzy modu­ła­mi i zewnętrz­ny­mi sys­te­ma­mi na rów­nych pra­wach. Rozwój sys­te­mu w takim przy­pad­ku pole­ga na two­rze­niu nowych modu­łów tym śro­do­wi­sku a nie na mody­fi­ka­cji już istniejących.

Kierunek ten już widać od ok. dwóch lat na ryn­ku (ja o tym pisze od ponad pię­ciu), pra­ce te więc trwa­ją zapew­ne znacz­nie dłu­żej. Widać to na stro­nach nie­któ­rych dostaw­ców, lide­rów na rynku:

Dynamics AX 2009. Framework (szkie­let, przyp. mój) to zestaw wzor­ców pro­jek­to­wych, inter­fej­sów, goto­wych biblio­tek i innych narzę­dzi. Elementy te dają wspar­cie pro­gra­mi­stom. Najlepszą prak­ty­ką jest się­ga­nie do tych zaso­bów i wyko­rzy­sty­wa­nie ich zamiast two­rzyć wła­sne podob­ne. Tu opi­sa­no fra­me­work, pod­sys­te­my i funk­cjo­nal­no­ści Microsoft Dynamix AX (źr. Frameworks Introduction).

Obecnie stan­dar­dem jest sto­so­wa­nie w fra­mer­wor­kach, prze­zna­czo­nych do two­rze­nia opro­gra­mo­wa­nia biz­ne­so­we­go w śro­do­wi­sku prze­glą­da­rek WWW, (i nie tyl­ko) wzor­ca pro­jek­to­we­go MVC:

Wzorzec MVC poma­ga two­rzyć apli­ka­cje roz­dzie­la­jąc trzy róż­ne aspek­ty opro­gra­mo­wa­nia: inter­fejs użyt­kow­ni­ka, logi­kę biz­ne­so­wą oraz zacho­wa­nie sys­te­mu, poprzez zacho­wa­nie mini­mal­nych wza­jem­nych zależ­no­ści. Wzorzec opi­su­je gdzie każ­dy z ele­men­tów tej logi­ki umiesz­czać. Interfejs użyt­kow­ni­ka obsłu­gu­je widok (view). Sterowanie apli­ka­cją obsłu­gu­je kon­tro­ler (con­trol­ler). Logika biz­ne­so­wa zawar­ta jest w mode­lu (model). Ta sepa­ra­cja poma­ga zarzą­dzać zło­żo­no­ścią opro­gra­mo­wa­nia pod­czas jego two­rze­nia, ponie­waż poma­ga sku­pić się w danym momen­cie na jed­nym tyl­ko aspek­cie pro­ble­mu. (źr. MSDN MVC Overwiew)

Inny przy­kład podej­ścia do otwar­cia się:

IFS Open Information Architecture

Tu mamy coś w rodza­ju fasa­dy ([[wzo­rzec pro­jek­to­wy fasa­da]]) dla IFS Application (mate­ria­ły z publicz­nej stro­ny WWW), któ­re­go nowa wer­sja to już nie śro­do­wi­sko pro­ce­dur w Oracle DBMS a ser­wer apli­ka­cyj­ny Java J2EE (cie­ka­we ilu pro­gra­mi­stów Java mają na eta­tach dostaw­cy IFS’a). Zapewne powyż­sze to nie jedy­ne przy­kła­dy tego rodza­ju roz­wią­zań ERP na ryn­ku (fir­my chcą­ce uzu­peł­nić ten arty­kuł mogą mi prze­słać sto­sow­ne materiały).

Tak więc da się, trze­ba nie tyl­ko chcieć ale i potra­fić. Tu mała łyż­ka dzieg­ciu do gar­nusz­ka inte­gra­to­rów i dostaw­ców ERP: naj­czę­ściej nie potra­fią i mam wra­że­nie, że nie chcą bo, jak już w poprzed­nim arty­ku­le pisa­łem, nie jest to w ich inte­re­sie.

Model biz­ne­so­wy dostaw­ców goto­we­go opro­gra­mo­wa­nia to w więk­szo­ści przy­pad­ków brak kosz­tów two­rze­nia wła­sne­go pro­duk­tu i jego roz­wo­ju i budo­wa­nie mar­ży na cudzym pro­duk­cie. Oferowany jest cudzy pro­dukt wraz usłu­gą jego wdro­że­nia. Firma taka sta­no­wi kanał sprze­da­ży pro­du­cen­ta tego opro­gra­mo­wa­nia. Problem w tym, że od pew­ne­go cza­su rynek się zmie­nia: goto­we pro­duk­ty bez mody­fi­ka­cji nie mają tu (zarzą­dza­nie) racji bytu a mam wra­że­nie, że dostaw­cy ERP sta­ra­ją się za wszel­ka cenę uni­kać dosto­so­wań. Dlaczego? Bo ich model biz­ne­so­wy wła­snie w więk­szo­ści przy­pad­ków nie prze­wi­du­je utrzy­my­wa­nia bar­dzo kosz­tow­ne­go zespo­łu ana­li­ty­ków, pro­jek­tan­tów i programistów.

Czy mam rację? Przejrzałem co nie­co ogło­szeń o pra­ce dostaw­ców ERP, z tego co zebra­łem skom­pi­lo­wa­łem naj­czę­ściej powta­rza­ją­ce się oczekiwania:

Konsultant sys­te­mów ERP
Osoba będzie człon­kiem zespo­łu bio­rą­ce­go udział w pro­ce­sie wdra­ża­nia sys­te­mu ERP (ana­li­za, kon­fi­gu­ra­cja, szko­le­nia) oraz zapew­nia­ją­ce­go bie­żą­cą obsłu­gę i ser­wis ist­nie­ją­cych wdrożeń.
Opis sta­no­wi­ska pracy
  • współ­pra­ca z klien­tem oraz doradz­two merytoryczne
  • udział w ana­li­zach wdrożeniowych
  • zaawan­so­wa­ne wspar­cie dla obec­nych klien­tów systemów
  • udział we wdra­ża­niu systemów
  • prze­pro­wa­dza­nie pre­zen­ta­cji pro­duk­tów u klienta
  • pro­wa­dze­nie szko­le­nia dla klientów
  • wspar­cie użyt­kow­ni­ków systemu
  • pro­wa­dze­nie doku­men­ta­cji technicznej,
  • zarzą­dza­nie zmia­na­mi w systemie,
  • szko­le­nie koń­co­wych użytkowników,
Oczekujemy:
  • 2 – 3 let­nie­go doświad­cze­nia we wdro­że­niach sys­te­mów kla­sy ERP
  • zdol­no­ści ana­li­tycz­ne­go myślenia
  • umie­jęt­no­ści roz­wią­zy­wa­nia problemów
  • doświad­cze­nie we wdra­ża­niu systemów
  • ogól­na orien­ta­cja w pro­ce­sach biz­ne­so­wych i chęć pogłę­bia­nia tej wiedzy,
  • zna­jo­mość meto­dy­ki zarzą­dza­nia pro­jek­ta­mi wdrożeniowymi
  • zna­jo­mo­ści SQL

To ostat­nie (SQL) poja­wia się od cza­su do cza­su, to kom­pe­ten­cja wyma­ga­na do two­rze­nia nowych rapor­tów w sys­te­mie. Gdzie tu jest inży­nie­ria opro­gra­mo­wa­nia? Czy w pań­stwa wdro­że­niach poza kon­sul­tan­ta­mi bra­li udział ana­li­ty­cy pro­jek­tan­ci i pro­gra­mi­ści czy tyl­ko kon­sul­tan­ci wpa­da­ją­cy po to by pozmie­niać coś w sys­te­mie (powo­du­jąc nie raz uszko­dze­nia w innych jego częściach)?

Tak więc co mogę pora­dzić? Bardzo dokład­ne przy­glą­da­nie się roz­dzia­łom ofer­ty pod tytu­łem Dostosowanie sys­te­mu, Koncepcja wdro­że­nia oraz ile ocze­ki­wa­nych przez Państwa funk­cjo­nal­no­ści to te, któ­rych sys­tem w swej wer­sji stan­dar­do­wej nie ofe­ru­je. Powinny one być po dokład­nej ana­li­zie, zapro­jek­to­wa­ne i zaimplementowane.

Jeżeli Konsultanci zaczy­na­ją nego­cjo­wać rezy­gna­cję z czę­ści ocze­ki­wań lub ofe­ru­ją coś podob­ne­go w sys­te­mie, to pierw­szy sygnał, że powi­nien ktoś im zacząć patrzeć na ręce, i nie mam tu na myśli ich przełożonego.

Na zakoń­cze­nie list jed­ne­go z moich klien­tów, nazwał bym to typo­wym problemem:

Planujemy wdro­że­nie nowe­go opro­gra­mo­wa­nia, chce­my tym razem unik­nąć pre­sji ze stro­ny dostaw­cy opro­gra­mo­wa­nia. Poprzednim razem dostaw­ca opro­gra­mo­wa­nia uprasz­czał sobie pra­cę, już na eta­pie ana­li­zy, któ­rą wyko­ny­wał sam. Analiza wyma­gań pole­ga­ła na wywia­dach i warsz­ta­tach gru­po­wych, skoń­czy­ła się zwy­kłym opi­sem, tabel­ka­mi i kil­ko­ma nie­czy­tel­ny­mi sche­ma­ta­mi. Podczas ana­li­zy i wdro­że­nia sta­le wma­wia­no nam, że tego nie moż­na”, to nale­ży upro­ścić” albo tak się nie robi” my zaś nie potra­fi­li­śmy tego oce­nić. Wiele naszych potrzeb odkry­wa­li­śmy dopie­ro pod­czas insta­la­cji kolej­nych pro­to­ty­pów, zaś dostaw­ca uni­kał wpro­wa­dza­nia zmian i obie­ca­nych dosto­so­wań. Dostaliśmy w efek­cie nie­przy­dat­ne i nie­zgod­ne z biz­ne­so­wy­mi potrze­ba­mi opro­gra­mo­wa­nie. Czy może nam Pan tym razem pomóc?

P.S.

Nie jestem w żaden spo­sób zwią­za­ny z dostaw­ca­mi pro­duk­tów wymie­nio­ny­mi w arty­ku­le. Ich nazwy zosta­ły wska­za­ne wyłącz­nie z sza­cun­ku dla praw autor­skich cyto­wa­nych treści.