Czego największe firmy technologiczne nie mówią swoim klientom?

Zasady panu­ją­ce na ryn­ku pro­duk­tów i usług IT wyda­ją się przej­rzy­ste: klient wyda­je pie­nią­dze na jakiś pro­dukt, ocze­ku­jąc w zamian okre­ślo­nych korzy­ści. Jak wyni­ka z udo­stęp­nio­nych przez Gartner Inc. ana­liz, fir­my reali­zu­ją przy oka­zji swo­ją stra­te­gię, o któ­rej wola­ły­by klien­tom nie mówić. Jakie są ich cele? […]

Omawiając stra­te­gie firm, Gaughan pod­kre­ślił rów­nież zna­cze­nie dzia­ła­ją­cych przy nich ośrod­ków badaw­czych. Ich nad­rzęd­nym celem jest two­rze­nie inno­wa­cji w takich spo­sób, aby ? zacho­wu­jąc pozo­ry roz­wo­ju ? utrzy­my­wać ist­nie­ją­cy stan rze­czy tak dłu­go, jak to tyl­ko moż­li­we.(źr. What Microsoft, Oracle, IBM, And SAP Don’t Tell Customers)

Skąd się u wie­lu użyt­kow­ni­ków tech­no­lo­gii IT bie­rze dług tech­no­lo­gicz­ny już w momen­cie pod­pi­sa­nia umo­wy na wdro­że­nie? Stąd, że zle­co­no ana­li­zę przed­wdro­że­nio­wą wyma­gań dostaw­cy tech­no­lo­gii, a w jego inte­re­sie jest dostar­czyć to co ma, a nie to cze­go potrze­bu­je klient. 

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.

SDJ – Pismo nie tylko dla programistów…

Okres waka­cyj­ny (kie­dy to było …) zaowo­co­wał sto­sem zale­głej lite­ra­tu­ry.… Dziś przy­szła pora na zale­głe nume­ry Software Developer Journal. Czasopismo adre­so­wa­ne głów­nie do pro­gra­mi­stów i archi­tek­tów ale jako ana­li­tyk i ja tak­że znaj­du­je tam nie raz coś ciekawego.

Czytaj dalej… SDJ – Pismo nie tyl­ko dla pro­gra­mi­stów…”

SOA: Czy to już nadchodzący koniec zintegrowanych ERP?

Przewiduję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych. Dotychczasowa ich zale­ta czy­li peł­na inte­gra­cja prze­sta­je być zale­tą a sta­je się gar­bem. System zin­te­gro­wa­ny moż­na już ?skle­ić? ze spe­cja­li­zo­wa­nych apli­ka­cji, kom­po­nen­tów. Technologia obiek­to­wa bar­dzo ten pro­ces uła­twi­ła. Drugim powo­dem prze­wi­dy­wa­ne­go odej­ścia od tej idei są ogrom­ne kło­po­ty z oce­ną ren­tow­no­ści wdro­że­nia sys­te­mu ERP. Nie raz jest to po pro­stu wręcz nie­moż­li­we z powo­du bra­ku moż­li­wo­ści oce­ny jakim kosz­tem wspie­ra­my poje­dyn­czy pro­ces biz­ne­so­wy bo trud­no z jed­ne­go ogrom­ne­go sys­te­mu wykro­ić koszt wspar­cia poje­dyn­cze­go pro­ce­su. Z tego też powo­du rośnie zain­te­re­so­wa­nie sys­te­ma­mi typu mid­dle­wa­re. Do tej pory były wyko­rzy­sty­wa­ne rzad­ko i dużych fir­mach, głów­nie w sek­to­rze finan­so­wym, głow­nie z uwa­gi na ich koszt. Obecnie roz­wią­za­nie to sta­je się coraz popu­lar­niej­sze. Dlatego?

Pojawienie się stan­dar­dów w mode­lo­wa­niu, usta­no­wie­nie mode­lo­wa­nia peł­no­war­to­ścio­wym eta­pem pro­jek­tu (a nie eks­tra­wa­gan­cją), otwie­ra­nie się tech­no­lo­gii, poja­wia­cie się stan­dar­dów wymia­ny meta­da­nych i mode­li toru­ją dro­gę do znacz­ne­go obni­że­nia kosz­tów i uspraw­nie­nia two­rze­nia sys­te­mów opar­tych o kom­po­nen­ty. To wszyst­ko powo­du­je, że nie trze­ba jed­ne­go wiel­kie­go sys­te­mu zin­te­gro­wa­ne­go. Wystarczy tak zwa­ny motor pro­ce­sów biz­ne­so­wych i spe­cja­li­zo­wa­ne sys­te­my, mogą one pocho­dzić od róż­nych pro­du­cen­tów i pra­co­wać na róż­nych platformach.

Jedyne cze­go trze­ba prze­strze­gać to pra­ca od samej góry: model biz­ne­so­wy orga­ni­za­cji, model pro­ce­sów biz­ne­so­wych, struk­tu­ra work­flow (sce­na­riu­sze dzia­łań czy­li wewnętrz­ny opis pro­ce­sów), lista ocze­ki­wa­nych usług sys­te­mu IT i sam sys­tem skła­da­ny z kom­po­nen­tów. Tak to widzę. Te trzy ele­men­ty: model biz­ne­so­wy, model pro­ce­sów, usłu­gi IT sta­no­wią pew­ną całość. Ubranie opi­su usług w cia­ło to wła­śnie obiek­to­we tech­no­lo­gie w IT, archi­tek­tu­ra SOA i MDA, języ­ki i nota­cje BPEL, BPMN, UML, XMI, obiek­to­we języ­ki programowania.

Koniec quasimonopolu dostawców systemów

No i oka­za­ło sie, że stan­dar­dy spraw­dzo­ne same się bro­nią. Microsoft W BizTalk Server będzie sup­por­to­wał BPEL (Business Proces Execution Language, opar­ty na XML język skryp­to­wy opi­su pro­ce­sów mię­dzy inny­mi w sys­te­mach BPM i work­flow mana­ge­ment uży­wa­ny już mię­dzy inny­mi w nie­któ­rych sys­te­mach CASE). Oracle tak­że ?rozu­mie? BPEL. Modelowanie sta­je się nor­mą a otwar­tość stan­dar­dem. Notacje UML i BPMN sta­ją się stan­dar­dem modelowania.

Co to zna­czy? Moim zda­niem to, że powo­li sta­je się coś o czym pisa­łem swe­go cza­su na stro­nach IT-Consulting. Monopolistę zaczę­li doga­niać kon­ku­ren­ci. Monopolista zaczy­na czuć poko­rę: już nie wyzna­cza sam stan­dar­dów de’fac­to (np. for­ma­ty pli­ków doku­men­tów, narzę­dzia pro­gra­mi­stycz­ne, inter­fej­sy komu­ni­ka­cyj­ne). Tracąc powo­li rynek na rzecz roz­wią­zań kon­ku­ren­cji dostrzegł, że to co było prze­wa­gą ryn­ko­wą (zamknię­te roz­wią­za­nia) sta­ło się w dal­szej per­spek­ty­wie hamul­cem. Przyszła pora na otwar­tość i kon­ku­ro­wa­nie jako­ścią a nie szan­taż ponad 80% udzia­łem w ryn­ku (vide współ­pra­ca Microsoft i Novell).

Kierunki rozwoju systemów IT

Albo ana­li­za pro­ce­so­wa i obiek­to­wa albo na mar­gi­nes życia. Coraz powszech­niej­sze zro­zu­mie­nie idei zorien­to­wa­nia na pro­ce­sy, inte­ro­pe­ra­cyj­no­ści (w tym zarzą­dza­nie łań­cu­cha­mi dostaw), archi­tek­tu­ry SOA (któ­ra moim zda­niem dosko­na­le się wpa­so­wu­je w meto­dy zarzą­dza­nia zorien­to­wa­ne­go na pro­ce­sy i reor­ga­ni­za­cję w fir­mach) powo­du­je sta­wia­nie takich wyma­gań tak­że dostaw­com roz­wią­zań IT. Te któ­re się do tego nie dosto­su­ją, moim zda­niem odej­dą z rynku.

Model biz­ne­so­wy fir­my, infor­ma­cje i dane jakich fir­ma wyma­ga do spraw­ne­go funk­cjo­no­wa­nia to już jeden orga­nizm. Stało się fak­tem, że żad­na fir­ma na ryn­ku już nie będzie w sta­nie kon­ku­ro­wać bez spraw­ne­go zarzą­dza­nia infor­ma­cją. Do zarzą­dza­nia infor­ma­cją i prze­twa­rza­nia danych zaś potrzeb­ne są spraw­nie dzia­ła­ją­ce i przede wszyst­kim łatwe w ich roz­wi­ja­niu sys­te­my. Warunek taki speł­nia­ją obec­nie zorien­to­wa­ne na pro­ce­sy sys­te­my two­rzo­ne w tech­no­lo­giach obiektowych.

Drugi waru­nek spraw­no­ści orga­ni­za­cji to opty­ma­li­za­cja jej wewnętrz­nej wydaj­no­ści. Tu wkra­cza­my dla odmia­ny w zarzą­dza­nie i jego pro­ce­so­wą natu­rę. Jak to pogo­dzić? Postrzegam tu wła­śnie miej­sce dla archi­tek­tu­ry SOA. Firmę i jej miej­sce w ryn­ko­wym łań­cu­chu war­to­ści moż­na, moim zda­niem, jed­no­znacz­nie opi­sać tyl­ko za pomo­cą mode­lu pro­ce­so­we­go zorien­to­wa­ne­go na pro­duk­ty. Zasoby (tu sys­tem IT) potrzeb­ne do reali­za­cji tej stra­te­gii ana­li­zu­je­my już obiektowo.

Namiastką takich opi­sów i ana­liz były pro­ce­du­ry w księ­gach jako­ści ISO. Do peł­nej ana­li­zy wyma­ga­ny jest jed­nak opis (mapa pro­ce­sów) uwzględ­nia­ją­cy cały obraz fir­my. SOA to archi­tek­tu­ra wska­zu­ją­ca natu­ral­ny pro­ces pro­jek­to­wa­nia sys­te­mów IT: model pro­ce­so­wy fir­my (orga­ni­za­cji), ana­li­za pro­ce­sów z per­spek­ty­wy zaso­bów IT jaki­mi mogą być wspie­ra­ne, na bazie tej ana­li­zy powsta­je lista usług na rzecz pro­ce­sów biz­ne­so­wych jakich ocze­ku­je­my od nowe­go systemu.

Następnie w pro­ce­sie ana­li­zy obiek­to­wej usłu­gi te trans­po­no­wa­ne są na model obiek­to­wy przy­szłe­go sys­te­mu IT. Analiza obiek­to­wa powin­na dać jako pro­dukt tak­że opis dzie­dzi­ny sys­te­mu czy­li repre­zen­ta­cję rze­czy­wi­stych obiek­tów w sys­te­mie. Jest to pod­sta­wa mode­lu danych dla powsta­ją­ce­go sys­te­mu. Kolejne eta­py to już pro­jekt obiek­to­we­go pro­gra­mu (apli­ka­cji) i jego implementacja.