Wstęp

Przyszła w koń­cu pora na model dzie­dzi­ny sys­te­mu i model sekwen­cji dla przy­pad­ków uży­cia. Wspomnę tak­że o wyma­ga­niach nie­funk­cjo­nal­nych. W poprzed­nim arty­ku­le: Diagram klas – czy­li re-inży­nie­ria” ana­li­zy biz­ne­so­wej c.d. Przypadki uży­cia i gra­ni­ce sys­te­mu opi­sa­łem pro­ces do powsta­nia opi­su przy­pad­ków uży­cia. Mamy za sobą pod­sta­wo­wą pra­cę z dzie­dzi­ny jaką jest ana­li­za sys­te­mo­wa. Postawiliśmy pro­blem do roz­wią­za­nia: jakie opro­gra­mo­wa­nie powin­no powstać. Pod poję­ciem jakie nale­ży rozu­mieć: co powin­no ono robić. Opracowano model, prze­te­sto­wa­no go. Oceniono dwa warian­ty (w dużym skró­cie ;)), w dru­gim warian­cie obsłu­ga płat­no­ści zosta­ła zle­co­na part­ne­ro­wi (out­so­ur­cing) i pod­ję­to racjo­nal­ną decy­zje o wybo­rze tego wariantu.

Po tej decy­zji mamy zamknię­ty zakres wyma­gań: sys­tem ma reje­stro­wać zamó­wie­nia i pozwa­lać na natych­mia­sto­we doko­na­nie płat­no­ści. Wiemy tak­że, że nasz sys­tem jest czę­ścią więk­szej cało­ści. Outsourcing to decy­zja hipo­te­tycz­ne­go spon­so­ra pro­jek­tu na bazie otrzy­ma­nych infor­ma­cji. Koniec ana­li­zy biznesowej.

Pora iść dalej. Tym razem pro­blem brzmi: kto i w jakiej tech­no­lo­gii ma wyko­nać to opro­gra­mo­wa­nie. Znowu przy­da­ły by się warian­ty czy­li róż­ne ofer­ty wyko­na­nia tego opro­gra­mo­wa­nia. Czego nam bra­ku­je by ofer­ty były porów­ny­wal­ne? Modelu tego co nale­ży wyko­nać! Czy moż­na jako ele­ment takie­go zapy­ta­nia dać model przy­pad­ków uży­cia? Z jed­nej stro­ny moż­na powie­dzieć, że owszem. W koń­cu mamy dokład­ny opis tego, jaki­mi cecha­mi (funk­cjo­nal­no­ści) ma się cha­rak­te­ry­zo­wać to co otrzy­ma­my. I robi tak więk­szość firm. Gdzie widzę kło­pot? Zapewne część czy­tel­ni­ków zauwa­ży­ła już, że pomi­ną­łem wyma­ga­nia poza-funkcjonalne.

Dygresja budowlana – pouczająca przygoda

Wyobraźmy sobie, że chce­my zle­cić budo­wę domu. Jego funk­cjo­nal­no­ści to mię­dzy inny­mi: oddziel­ne miej­sca do spa­nia oraz czy­ta­nia i oglą­da­nia tele­wi­zji (tak zwa­ny salon). Kuchnia złą­czo­na z salo­nem. Łazienka na każ­dym pię­trze. Wejście z zewnątrz do salo­nu poprzez mały przed­po­kój. Garaż połą­czo­ny z przed­po­ko­jem. I jesz­cze wie­le innych. Wymagania poza-funk­cjo­nal­ne, tych może być ogrom! Dom ma być ład­ny, nie może być podob­ny do domu sąsia­da, musi speł­niać wyma­ga­nia pra­wa budow­la­ne­go, kolo­ry­sty­ka dachu powin­na być sko­re­lo­wa­na z ele­wa­cją, bie­żą­ce kosz­ty ogrze­wa­nia powin­ny być moż­li­wie jak naj­niż­sze, dom powi­nien dać się w przy­szło­ści łatwo roz­bu­do­wać o dwa nowe pomiesz­cze­nia. Dom powi­nien być przy­go­to­wa­ny do poten­cjal­nej insta­la­cji kom­pu­te­ra w każ­dym poko­ju. Powinno być moż­li­we zain­sta­lo­wa­nie kli­ma­ty­za­cji w cią­gu trzech lat od zakoń­cze­nia inwestycji.

Taki doku­ment może mieć dzie­siąt­ki stron, wery­fi­ka­cja jego tre­ści (spój­ność, tech­nicz­na nie­sprzecz­ność, inne) może być trud­na. Opracowanie go w gro­nie np. czte­ro­oso­bo­wej rodzi­ny będzie wyzwa­niem już tyl­ko w kate­go­riach nego­cja­cji ;). Żeby zabez­pie­czyć się przed inter­pre­ta­cją” wyko­naw­cy doku­ment będzie obra­stał w szcze­gó­ły, ale takie o któ­rych pomy­ślą auto­rzy doku­men­tu: rodzi­na. Jakie mają w tym doświad­cze­nie? Większość tych ocze­ki­wań to wła­snie poza funk­cjo­nal­ne życzenia!.

Jak unik­nąć tej bene­dyk­tyń­skiej pra­cy, któ­rej ryzy­ko rośnie wraz z roz­ro­stem doku­men­tu? Idziemy do archi­tek­ta. Nasza rodzi­na idzie do archi­tek­ta, ten na bazie powyż­szych opo­wie­ści dopro­wa­dza do jakiejś kon­cep­cji roz­wią­za­nia (pro­jekt wstęp­ny, kon­cep­cyj­ny). W momen­tach spo­ru peł­ni role media­to­ra (łazien­ka ma być przy salo­nie czy przy poko­ju dzie­ci), poka­zu­je na mode­lu (pro­jekt kon­cep­cyj­ny, któ­ry ewo­lu­uje w trak­cie takiej roz­mo­wy) wady i zale­ty obu roz­wią­zań, pozwa­la rodzi­nie pod­jąć świa­do­mą decy­zje. Zaletą wizy­ty u archi­tek­ta, zanim zapy­ta­my jakie­go­kol­wiek deve­lo­pe­ra, jest to, że archi­tekt jest wol­ny od jakich­kol­wiek uprze­dzeń czy przy­zwy­cza­jeń. W każ­dej dzie­dzi­nie inży­nie­rii wyko­naw­cy są wyspe­cja­li­zo­wa­ni, jeśli damy im wybór, będą sto­so­wa­li tech­no­lo­gie naj­mniej ryzy­kow­ne dla sie­bie (naj­le­piej pozna­ne) a nie opty­mal­ne dla inwe­sto­ra i to jest oczy­wi­ste.

Dlatego war­to naj­pierw iść do archi­tek­ta, ten nie­ska­żo­ny tech­no­lo­gia­mi (bo nie ma w tym żad­ne­go inte­re­su), opra­cu­je nam pro­jekt funk­cjo­nal­ny, ale zawie­ra­ją­cy pew­ne szcze­gó­ły roz­wią­zań (np. zabro­ni budo­wy beto­no­wej ścia­ny w miej­scu gdzie my ocze­ku­je­my przy­szłej roz­bu­do­wy). Popatrzymy na coś, co potra­fi­my szyb­ko oce­nić nie tyl­ko od stro­ny wyma­gań funk­cjo­nal­nych (musz­la pod pół­ką speł­nia sta­wia­ne jej wyma­ga­nia ale czy jest to wygod­ne?) Na pro­jek­cie od razu wychwy­ci­my, cze­go w tek­ście opi­su raczej nigdy: ele­men­ty este­ty­ki, wygo­dy, pod­ję­te kom­pro­mi­sy będą dla wszyst­kich zro­zu­mia­łe i nie będą w przy­szło­ści podważane.

Diagram klas czy model dziedziny – co ma powstać?

(pro­gra­mi­ści mogą to pominąć)

Otóż [[dia­gram klas]] ([[UML]]) to narzę­dzie podob­ne do rysun­ku tech­nicz­ne­go. Ważne jest to co on przed­sta­wia i to nale­ży naj­pierw zde­fi­nio­wać (dopó­ki nie wiem czy mam napi­sać: książ­kę czy roz­dział pod­ręcz­ni­ka, nie wiem co mam w tym języ­ku wyra­zić). Tak więc coś nale­ży zało­żyć. Podstawowym zało­że­niem jakie tu przyj­mę jest: nie two­rzy­my opro­gra­mo­wa­nia od zera. A wiec od cze­go? Wiele firm pro­gra­mi­stycz­nych uży­wa goto­wych szkie­le­tów opro­gra­mo­wa­nia, tak zwa­nych [[framework]]ów. Są to goto­we, naj­czę­ściej dzie­dzi­no­we (adre­so­wa­ne dla kon­kret­nej dzie­dzi­ny zasto­so­wań) biblio­te­ki pod­pro­gra­mów (klas w tech­no­lo­giach obiektowych).

Obejmują zazwy­czaj typowe,uniwersalne funk­cjo­nal­no­ści takie jak logo­wa­nie, wyświe­tla­nie tre­ści na ekra­nie, zapis do bazy danych (a tak na praw­dę utrwa­la­nie, bo baza danych to nie jedy­ny spo­sób) , ste­ro­wa­nie zacho­wa­niem się apli­ka­cji, ele­men­ty bez­pie­czeń­stwa i wie­le innych. Funkcjonalności więk­szo­ści biz­ne­so­wych apli­ka­cji moż­na podzie­lić na trzy gru­py: ste­ro­wa­nie pro­gra­mem, obsłu­ga inter­fej­su użyt­kow­ni­ka oraz funk­cjo­nal­no­ści spe­cy­ficz­ne dla dzie­dzi­ny (miej­sca) zasto­so­wa­nia. Mamy więc dzie­dzi­nę pro­ble­mu, inter­fejs użyt­kow­ni­ka i ste­ro­wa­nie cało­ścią. Innymi sło­wy mamy: Model, View (wido­ki), Controller (ste­ro­wa­nie) czy­li naj­po­pu­lar­niej­szy obiek­to­wy wzo­rzec pro­jek­to­wy apli­ka­cji o wdzięcz­nej nazwie [[MVC]].

Wniosek z tego taki, że jeśli zało­ży­my, że taki szkie­let zosta­nie uży­ty (a może­my to zapi­sać w wyma­ga­niach poza-funk­cjo­nal­nych dla wyko­naw­cy) to pozo­sta­je po zakoń­czo­nej ana­li­zie biz­ne­so­wej doko­nać ana­li­zy obiek­to­wej i zapro­jek­to­wać [[model dzie­dzi­ny sys­te­mu]]. Narzędziem do jego poka­za­nia jest wła­śnie dia­gram klas nota­cji UML.

Model dziedziny systemu Zamówienia

Tak więc wszyst­ko jasne 🙂 wiec do robo­ty. Pierwszy etap to opra­co­wa­nie listy obiek­tów biz­ne­so­wych. Tu wkra­cza kolej­na meto­da, któ­ra sto­su­ję: obiek­ty dzie­li­my na narzę­dzia i przed­mio­ty prze­twa­rza­ne z pomo­cą tych narzę­dzi, pamię­ta­my, że tego wszyst­kie­go ktoś uży­wa: nasz aktor. Prosty przy­kład: Do wysta­wie­nia fak­tu­ry potrzeb­ne są: for­mu­larz fak­tu­ry (oczy­wi­ste) i fak­tu­rzy­sta (ktoś musi wie­dzieć co nale­ży zro­bić). Pierwszy sto­pień inno­wa­cji: kal­ku­la­tor dla fak­tu­rzy­sty. Kolejny sto­pień to elek­tro­nicz­ny for­mu­larz. Obiekty biz­ne­so­we: wzór for­mu­la­rza fak­tu­ry, kal­ku­la­tor, fak­tu­rzy­sta oraz oczy­wi­ście kuwet­ka na wysta­wio­ne fak­tu­ry. Dlaczego tak?

Kolejna meto­da ana­li­zy i pro­jek­to­wa­nia powią­za­na z wzor­cem MVC: [[Domain Driven Design]] (pro­jek­to­wa­nie opro­gra­mo­wa­nia bazu­ją­ce na mode­lu dzie­dzi­ny sys­te­mu) czy­li DDD. O co tu cho­dzi? Ogólnie o to by pro­jek­to­wać opro­gra­mo­wa­nie dość wier­nie symu­lu­jąc (a raczej odwzo­ro­wu­jąc) pozna­ną rze­czy­wi­stość. Dlaczego? Bo osią­ga­my bar­dzo waż­ną korzyść: nawet jeże­li nie uda nam się odkryć sen­su ist­nie­nia jakie­goś obiek­tu, mimo wszyst­ko mode­lu­je­my go bez uprosz­czeń, dzię­ki temu w przy­szło­ści, roz­wi­ja­jąc sys­tem, nie nadzie­je­my się na pro­blem wywo­ła­ny takim uprosz­cze­niem gdyż takie począt­ko­we uprosz­cze­nie sta­je się nie raz poważ­nym ogra­ni­cze­niem. Druga zale­ta: model taki jest rela­tyw­nie łatwiej­szy do per­cep­cji niż model z uprosz­cze­nia­mi, w szcze­gól­no­ści total­nie nie­straw­ny dla zwy­kłych ludzi (czy­ta: nie­we­ry­fi­ko­wal­ny przez zama­wia­ją­ce­go) [[model rela­cyj­ny w trze­ciej posta­ci nor­mal­nej]]. Tu bar­dzo prze­pra­szam czy­tel­ni­ków biz­ne­so­wych, że uży­łem nie­zro­zu­mia­łych zapew­ne dla nich pojęć, ale to wła­śnie poka­zu­je, że na tym eta­pie zama­wia­ją­cy tra­ci kon­takt (zro­zu­mie­nie) z wyko­naw­ca tego co sam zamó­wił zamawiający.

Z mode­lu pro­ce­su dowia­du­je­my się, że nastę­pu­ją­ce obiek­ty bio­rą udział w reali­za­cji potrzeb­nych nam funk­cjo­nal­no­ści: Formularz Zamówienia i koniec! Na pew­no? Nie 🙂 bo chce­my by jed­nak by był to auto­ma­tycz­ny sys­tem inter­ne­to­wy, wiec potrzeb­ny jest Zarządca. On wie: jak przyj­mo­wać Zamówienia oraz skąd brać dane i gdzie je wysy­łać. Klient (zama­wia­ją­cy) jest tu akto­rem i nie jest on abso­lut­nie obiek­tem biz­ne­so­wym do imple­men­ta­cji. Mamy więc dwa obiek­ty biz­ne­so­we: Zarządca i FormularzZamówienia. Do tego mamy inter­fej­sy dla ERP i do Płatności. A gdzie baza danych? Nie ma! Co robić? Wiem! Kuwetka :), potrzeb­na mi kuwet­ka. Baza danych to dla biz­ne­su sło­wo obrzy­dli­we i nie uży­wa­my go. Mamy więc: Zarządca, Kuwetka, FormularzZamówienia, .… aaaaaaaa, a same Zamówienia? :). Komplet:

  1. FormularzZamówienia
  2. GeneratorDruczków
  3. Kuwetka
  4. Zarządca
  5. Zamówienia

Nie zapo­mi­na­my, że mamy Framework i inter­fej­sy (ERP i Płatności). Pojawił się jesz­cze GeneratorDruczków. Skąd się wziął? Kolejna meto­da pro­jek­to­wa­nia: [[Role, odpo­wie­dzial­ność, współ­pra­ca]]. Otóż, war­to Zarządcę zwol­nić z obo­wiąz­ku posia­da­nia wie­dzy o aktu­al­nych wzo­rach doku­men­tów. Te wie­dzę o aktu­al­nie sto­so­wa­nych wzo­rach doku­men­tów (i rolę) posia­da GeneratorDruczków. I mógł by ktoś powie­dzieć, że nie­po­trzeb­nie kom­pli­ku­je pro­gram. Owszem, skom­pli­ko­wał się. Jeśli jed­nak w pro­gra­mie poja­wią się kie­dyś nowe funk­cjo­nal­no­ści, inni Zarządcy, wszy­scy będą pobie­ra­li drucz­ki z jed­ne­go miej­sca bez zasta­na­wia­nia się czy są wła­ści­we bo mamy tyl­ko jed­no ich źró­dło, któ­re odpo­wia­da za to by zawsze były właściwe.

Jak wyglą­da dia­gram klas:

Diagram klas, model dziedziny systemu

Tak więc co my tu mamy, po kolei: Klient (nasz aktor) kon­tak­tu­je się wyłącz­nie z Zarządcą, któ­ry go obsłu­gu­je. Zarządca korzy­sta z usług GeneratoraDruczków, Kuwetki, zewnętrz­nych sys­te­mów poprzez inter­fej­sy. Koniec. Co dalej? Ano wypa­da­ło by poka­zać jak Zarządca, zda­niem pro­jek­tan­ta (:)) reali­zu­je nasz przy­pa­dek uży­cia. Na potrze­by usys­te­ma­ty­zo­wa­nia pro­jek­tu przy­to­cze jesz­cze raz sce­na­riusz w fir­mie trosz­kę sformalizowanej:

uc_scenariusz

Taka postać sce­na­riu­sza (dia­log) pozwa­la upew­nić się, że zama­wia­ją­cy i pro­jek­tant myślą tak samo. Mały komen­tarz: Klient ma przed sobą Ekran Startowy i wybie­ra opcję (pole­ce­nie) Nowe Zamówienie. System pyta o NIP, Klient wpi­su­je NIP i potwier­dza. Możliwe jest nie wpi­sa­nie NIP. System wyświe­tla for­mat­kę nowe­go zamó­wie­nia. Formatka ma wypeł­nio­ne dane Zamawiającego lub nie, jeśli nie poda­no NIPu albo nie zna­le­zio­no go na liście kon­tra­hen­tów. Klient wpro­wa­dza dane poprzez zazna­cze­nie tego co chce zamó­wić, wpi­su­je ilo­ści itp. na koniec potwier­dza. System spraw­dza i wyświe­tla kom­plet­ne zmó­wie­nie. Klient zatwier­dza lub rezy­gnu­je (pomi­ną­łem, ewen­tu­al­ną edy­cję dla uprosz­cze­nia, jeże­li fir­ma ofe­ru­je tysią­ce pro­duk­tów tak­że będzie inaczej :)).

W tym momen­cie Klient ma jed­no lub wię­cej zamó­wień do opła­ce­nia, w kolej­nym przy­pad­ku uży­cia może zazna­czyć zamó­wie­nia do opła­ce­nia i wybrać opcję Inicjacja Płatności, System przy­go­tu­je nie­zbęd­ne dane i prze­ka­że ste­ro­wa­nie do Systemu obsłu­gi Płatności. Nie będzie tu tego opi­su, celem arty­ku­łu jest poka­za­nie meto­dy a nie wyko­na­nie kom­plet­ne­go projektu.

Powyższy sce­na­riusz posłu­ży teraz do prze­te­sto­wa­nia i uzu­peł­nie­nia mode­lu dzie­dzi­ny i uzu­peł­nie­nia go (ten etap nazy­wa­ny jest czę­sto pro­of-of-con­cept). Narzędziem do testo­wa­nia będzie dia­gram sekwencji.

Samo wyko­na­nie dia­gra­mu pozwa­la na spraw­dze­nie popraw­no­ści pomy­słu i jego logi­ki oraz od razu daje nam moż­li­wość wery­fi­ka­cji atry­bu­tów i ope­ra­cji. Po tym teście (opra­co­wa­nie tego dia­gra­mu jest testem kon­cep­cji) uzu­peł­nia­my model dzie­dzi­ny o atry­bu­ty i ope­ra­cje. Diagram klas to sta­tycz­ny opis, któ­ry sam z sie­bie nicze­go nie mówi o współ­pra­cy obiek­tów. Jego popraw­na inter­pre­ta­cja (nie licząc sys­te­mu pojęć) jest nie­moż­li­wa bez tego mode­lu dyna­mi­ki (dia­gram sekwen­cji to model dyna­mi­ki sys­te­mu). Zaryzykował bym nawet tezę, że sam dia­gram klas nie nie­sie pra­wie żad­nej infor­ma­cji wykonawcy.

Model dzie­dzi­ny wzbo­ga­cił się:

model-dziedziny_0

Podsumowanie

Przytoczę ponow­nie cyto­wa­ny dia­gram klas:

uml2_diagram_klas6_modelowaniewordpresscom

Powyższy dia­gram w moim mnie­ma­niu jest raczej pew­nym mode­lem poję­cio­wym. Bez kil­ku słów o meto­dy­ce pro­jek­to­wa­nia trud­no go w ogó­le oce­niać dla­te­go poka­za­łem swój dia­gram klas, i spo­sób w jaki powstał. Kluczowe różnice:

  1. W moim mode­lu typ płat­no­ści będzie atry­bu­tem Zamówienia
  2. Obiekt Zamówienie, poza zawar­to­ścią dru­ku zamó­wie­nia, obsłu­gu­je tak­że inne dodat­ko­we zada­nia (pamię­ta­nie o spo­so­bie płat­no­ści, przy­go­to­wa­nie seria­li­za­cji XML do wsa­dze­nia” obiek­tu do ERP, może coś jeszcze…)
  3. Klient w ogó­le się nie poja­wia, chy­ba już wia­do­mo dlaczego…
  4. Pozycja zamó­wie­nia zosta­ła ukry­ta” w zamó­wie­niu, zależ­nie od kon­cep­cji były by to ele­men­ty agre­ga­tu (pozy­cje­za­mó­wie­nia u mnie były by w rela­cji kom­po­zy­cji do obiek­tu bazo­we­go DrukZamówienia), nie ma kla­sy Produkt (maga­zyn), jest to obiekt za któ­ry odpo­wia­da sys­tem ERP.
  5. U mnie poja­wia się Kuwetka, obiekt odpo­wie­dzial­ny za skła­do­wa­nie Zamówień, pyta­nia o kon­kret­ne Zamówienie, ostat­nie zamó­wie­nie, zesta­wie­nie zamó­wień za okres to poten­cjal­ne ope­ra­cje obiek­tu Kuwetka.
  6. Pojawia się tak­że Zarządca, obiekt odpo­wie­dzial­ny za obsłu­gę przy­pad­ku uży­cia (byc może tak­że innych). Na dia­gra­mie sekwen­cji poja­wi­ła się kla­sa System obsługi…jest to abs­trak­cja ele­men­tu View wzor­ca MVC.

Powyższy pro­jekt jest bar­dzo uprosz­czo­ny i na pew­no ma wie­le wad, kil­ka ite­ra­cji pro­jek­to­wa­nia i testów war­to by jesz­cze prze­pro­wa­dzić. Celem moim jed­nak było poka­za­nie samej meto­dy ana­li­zy i pro­jek­to­wa­nia, tego do cze­go moż­na użyć nota­cji UML. Pokazać, że moż­na zapro­jek­to­wać logi­kę opro­gra­mo­wa­nia i ją prze­te­sto­wać nie pisząc nawet linij­ki kodu.

Na koniec chcia­łem poka­zać, że w pro­jek­tach dedy­ko­wa­nych, jeże­li jest nawet cień ryzy­ka, że wyko­naw­ca będzie błą­dził reali­zu­jąc nasz pro­jekt (nie ocze­kuj­my od pro­gra­mi­stów, że będą zna­li i rozu­mie­li naszą fir­mę, nie taka jest ich rola) war­to wyko­nać taki wła­śnie pro­jekt. Po pierw­sze prze­te­stu­je­my nasze życze­nia, po dru­gie powsta­nie mate­riał, na bazie któ­re­go kil­ku wyko­naw­ców doko­na wyce­ny z nie­wiel­kim błę­dem i bez dużych narzu­tów na nie­spo­dzian­ki. Czy takie pro­jek­ty robią deve­lo­pe­rzy? Ich o to pytaj­cie. Czy ma to sens? Testowanie dia­gra­mów jest co naj­mniej o rząd wiel­ko­ści tań­sze niż testo­wa­nie pro­to­ty­pów przez programistów.

Kto powi­nien opra­co­wać taki pro­jekt? Osobiście uwa­żam, że nie powi­nien to być wyko­naw­ca pro­jek­tu. Powodem jest po pierw­sze to, o czym wspo­mnia­łem: każ­dy się spe­cja­li­zu­je w jakiejś jed­nej tech­no­lo­gii. Po dru­gie w przy­pad­ku jakich­kol­wiek pro­ble­mów Zamawiający, jako nie­spe­cja­li­sta, nie ma żad­nej moż­li­wo­ści mery­to­rycz­nej oce­ny wyko­naw­cy, nawet gdy­by był szko­dli­wy dla zama­wia­ją­ce­go. Nie twier­dzę, że wszy­scy deve­lo­pe­rzy to nie­kom­pe­tent­ni nacią­ga­cze ale też nie dam gło­wy, że takich nie ma. Sugeruję naśla­do­wa­nie ryn­ku budow­la­ne­go: zarzą­dza­nie ryzy­kiem czy­li oddzie­le­nie pro­jek­to­wa­nia od wykonania.

Developer tak­że odno­si tu pew­ną korzyść: jest zwol­nio­ny z odpo­wie­dzial­no­ści i posą­dza­nia go o kom­bi­no­wa­nie, zysku­je dodat­ko­wo media­to­ra pomię­dzy sobą i zama­wia­ją­cym. Minus jest taki, że wyna­gro­dze­nie za ana­li­zę i pro­jekt nie wpły­nie do jego kie­sze­ni ale cóż… to koszt kom­for­tu pra­cy ale z regu­ły nie prze­kra­cza on 10 – 20% budże­tu na powsta­nie oprogramowania.

Podsumowanie drugie

Czy to ma sens w przy­pad­ku goto­wych ERP? Moim zdaniem:

  1. Ingerencja (tak zwa­na kasto­mi­za­cja) w goto­we opro­gra­mo­wa­nie ERP koń­czy się bar­dzo czę­sto desta­bi­li­za­cją pier­wot­nie dobre­go oprogramowania.
  2. Jeżeli sys­tem ERP jest zamknię­ta bry­łą (z regu­ły świad­czy o tym fakt pra­cy na rela­cyj­nej, znor­ma­li­zo­wa­nej bazie danych) nie war­to go kastro­mi­zo­wać bo to kosz­tow­ny i bar­dzo ryzy­kow­ny pro­ces, do tego pozba­wia­my się moż­li­wo­ści pro­ste­go jego upgrade’owania.

Brakujące w fir­mie funk­cjo­nal­no­ści lepiej two­rzyć osob­no, jako dedy­ko­wa­ne pro­jek­ty bo to po pierw­sze chro­ni inwe­sty­cję w ERP, po dru­gie z regu­ły kosz­tu­je znacz­nie mniej i znacz­nie szyb­ciej jest goto­we do uży­cia (stwo­rze­nie małe­go opro­gra­mo­wa­nie jest dużo prost­sze niż mody­fi­ka­cja duże­go). Po dru­gie poja­wia­ją się już sys­te­my ERP mają­ce struk­tu­rę wła­snie szkie­le­tu opar­te­go na wzor­cu MVC i zapro­jek­to­wa­nie nowej funk­cjo­nal­no­ści pole­ga na ana­li­zie i pro­jek­to­wa­niu takim jak wyżej opi­sa­ne, z tą róż­ni­cą że imple­men­ta­cja ma miej­sce w śro­do­wi­sku tego ERP a nie w śro­do­wi­sku odręb­ne­go narzę­dzia pro­gra­mi­stycz­ne­go. Tak więc, paradoksalnie,

powyż­sze ana­li­za i pro­jek­to­wa­nie powin­ny być zawsze pierw­szym eta­pem pro­jek­tu pro­gra­mi­stycz­ne­go nie­za­leż­nie od tego czy ma powstać nowe opro­gra­mo­wa­nie czy tyl­ko nowe funk­cjo­nal­no­ści do ist­nie­ją­ce­go.

A gdzie się podzia­ły wyma­ga­nia pozafunkcjonalne?

Generalnie w mojej meto­dy­ce są one ogra­ni­cze­nia­mi doku­men­to­wa­ny­mi dla każ­de­go przy­pad­ku uży­cia indy­wi­du­al­nie. Powstaje repo­zy­to­rium ogra­ni­czeń i mapo­wa­nie ich na przy­pad­ki uży­cia. Bardzo restryk­cyj­ne ogra­ni­cze­nia (np. wyso­ka dostęp­ność) mogą być wydzie­lo­ne z ich przy­pad­ka­mi uży­cia do osob­ne­go pod­sys­te­mu i imple­men­to­wa­ne nawet na osob­nej plat­for­mie jeśli taka będzie potrze­ba zwią­za­na z ren­tow­no­ścią. To jed­nak temat na osob­ny artykuł :).

Konkluzja biz­ne­so­wa: Nowy sys­tem infor­ma­tycz­ny to inte­rak­cja fir­my i opro­gra­mo­wa­nia, musi być trak­to­wa­na łącz­nie jako jeden sys­tem zło­żo­ny z ludzi i narzę­dzi w ich oto­cze­niu. Dlatego decy­zja biz­ne­so­wa o out­so­ur­cin­gu płat­no­ści i inte­gra­cji z ERP powin­na być moim zda­niem inte­gral­ną czę­ścią i pro­duk­tem ana­li­zy biz­ne­so­wej w pro­jek­cie informatycznym. 

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 5 komentarzy

  1. Podsumowując tę serię arty­ku­łów – dosta­je­my taką kolejność?
    1. User story
    2. Model procesu
    3. Taksonomia
    4. Model dziedziny
    5. Scenariusz Użytkownik – System
    6. Diagram sekwen­cji – testo­wa­nie mode­lu dziedziny
    7. Model dzie­dzi­ny – uzu­peł­nie­nie o atry­bu­ty i metody

    1. Jarek Żeliński

      oso­bi­ście User Story (dekla­ra­tyw­ne opi­sy przy­szłych użyt­kow­ni­ków) zastę­pu­ję ana­li­zą dokumentów … 

  2. Jakub T

    Będę bar­dzo wdzięcz­ny za uzu­peł­nie­nie dia­gra­mu sekwen­cji, obec­nie wyświe­tla się tylko:
    „[sin­gle­pic id=73 w=320 h=240 float=center]”

Dodaj komentarz

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