Struktury formularzy jako forma wyrażania wymagań

Wprowadzenie

Ten arty­kuł to uzu­peł­nie­nie opi­su: Dokument jako wyma­ga­nie.

Często jestem i ja pyta­ny o to Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?” Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. Zauważyli to tak­że inni:

A Mock-up is a sli­gh­tly glo­ri­fied pic­tu­re, so you will be answe­ring with at least 1001 words ! 

Bardzo czę­sto widu­ję wyma­ga­nia spi­sy­wa­ne jako tak zwa­na lista funk­cji lub funk­cjo­nal­no­ści. Pojęcia te mają takie defi­ni­cje w języ­ku polskim: 

funk­cja ?zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz?, ?moż­li­wość wyko­na­nia okre­ślo­nej ope­ra­cji przez urzą­dze­nie lub pro­gram komputerowy?

Funkcjonalność jest defi­nio­wa­na jako funk­cja cze­goś w jakimś systemie. 

Czytaj dalej… Struktury for­mu­la­rzy jako for­ma wyra­ża­nia wyma­gań”

Analiza procesowa a obiektowa czyli niedopasowanie oporu

Swego cza­su w arty­ku­le o Wścipskim Analityku uza­sad­nia­łem potrze­bę pano­wa­nia nad wyma­ga­nia­mi od momen­tu poja­wie­nia się potrze­by biz­ne­so­wej aż do jej imple­men­ta­cji. Nie zna­czy to abso­lut­nie, że ana­li­tyk ma pro­gra­mo­wać, zna­czy to jed­nak, że ana­li­tyk powi­nien doku­men­to­wać to cze­go żąda w wyma­ga­niach a potem nad­zo­ro­wać realizację.

Developerzy uzur­pu­ją sobie pra­wa do wszyst­kie­go co wią­że się z imple­men­ta­cją. Z jed­nej stro­ny czę­sto żąda­ją szcze­gó­ło­wych danych np. o danych z dru­giej stro­ny sami chcą opi­sać ich logi­kę biz­ne­so­wą (tak, bo dane biz­ne­so­we to logi­ka biz­ne­so­wa a nie tech­no­lo­gia). Do tego bar­dzo wie­lu deve­lo­pe­rów sto­su­je meto­dy pra­cy rodem z przed kil­ku­na­stu lat… We wspo­mnia­nym wyżej arty­ku­le napi­sa­łem mię­dzy inny­mi o tak zwa­nym para­dyg­ma­cie obiek­to­wym i wie­dzy o nim u deve­lo­pe­rów, szu­kam hasła ana­li­za pro­ce­so­wa” i para­dyg­mat obiektowy”:

Tradycyjnie idzie­my do WIKI:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza pro­ce­so­wa? w Wikipedii. (24 Maj 2011)

No cóż, szu­ka­my dalej:

Process ana­ly­sis pre­sents a chro­no­lo­gi­cal sequ­en­ce of steps that expla­in how some­thing is done, how some­thing hap­pens, or how readers can do some­thing. (źr. http://​www​.tcc​.edu/​s​t​u​d​e​n​t​s​/​r​e​s​o​u​r​c​e​s​/​w​r​i​t​c​e​n​t​/​h​a​n​d​o​u​t​s​/​w​r​i​t​i​n​g​/​p​r​o​c​e​s​s​.​htm).

Coś mamy: ana­li­za pro­ce­so­wa pre­zen­tu­je w posta­ci chro­no­lo­gicz­nej sekwen­cji kro­ków, to jak coś powsta­je, co się wyda­rza lub jak moż­na coś zro­bić. Piękna defi­ni­cja. Ta pre­zen­ta­cja to, w kon­tek­ście biz­ne­so­wym, model (mapa) pro­ce­sów biznesowych.

Mamy wiec upo­rząd­ko­wa­ną wie­dzę o fir­mie (orga­ni­za­cji) zama­wia­ją­ce­go opro­gra­mo­wa­nie. Tu tak­że powsta­je opis tego po co i gdzie tego opro­gra­mo­wa­nia chce­my uży­wać: model procesowy.

Tak zwane niedopasowanie oporu

Tak jest nazy­wa­na w lite­ra­tu­rze róż­ni­ca pomię­dzy para­dyg­ma­tem pro­ce­so­wym a obiek­to­wym. Paradygmat pro­ce­so­wy ope­ru­je taki­mi poję­cia­mi jak: pro­ces, wej­ście pro­ce­su, wyj­ście pro­ce­su, zda­rze­nie, wyko­naw­ca pro­ce­su (zaso­by), czyn­ność (lub ich sekwen­cja). Paradygmat obiek­to­wy to wspo­mnia­ne współ­pra­cu­ją­ce obiek­ty. W czym pro­blem? W przej­ściu z mode­lu pro­ce­so­we­go na obiek­to­wy. Czy to łatwe? Nie. Jak to zro­bić? Hm… usiąść i popra­co­wać nad tym.

Należy prze­pro­wa­dzić ana­li­zę obiek­to­wą i wyko­nać model obiek­to­wy. Czego? Kodu? Nie! Logiki dzia­ła­nia i orga­ni­za­cji zamawiającego!

Tak wła­śnie jest: ana­li­za obiek­to­wa i mode­lo­wa­nie obiek­to­we to nie pro­gra­mo­wa­nie. Programowanie (wraz z pro­jek­to­wa­niem ele­men­tów czy­sto tech­nicz­nych) to imple­men­ta­cja modelu.

Jak moż­na radzić sobie z tym nie­do­pa­so­wa­niem”. Pomagają w tym zasa­dy SOLID (w szcze­gól­no­ści zasa­da otwar­to­ści na roz­sze­rze­nia i zamknię­cia na mody­fi­ka­cje oraz pro­jek­to­wa­nie zorien­to­wa­ne na zobo­wią­za­nia klas) oraz wzor­ce DDD w ana­li­zie i projektowaniu.

To co tu opi­szę nie jest pro­stym algo­ryt­mem mode­lo­wa­nia”, z pra­cy myślo­wej niko­go tu nie zwol­nię. Moim celem jest uzu­peł­nie­nie arty­ku­łu o sza­chow­ni­cy i arty­ku­łu o zbyt Niskim pozio­mie ana­li­zy o wska­za­nie, że model dzie­dzi­ny jest bar­dziej ele­men­tem ana­li­zy i mode­lo­wa­nia biz­ne­so­we­go niż pro­jek­to­wa­nia i imple­men­ta­cji. Model ten to jed­no z klu­czo­wych wyma­gań: sys­tem ma reali­zo­wać logi­kę opi­sa­ną w mode­lu dziedziny.

Jeżeli uzna­my, że moż­na (taki) model dzie­dzi­ny imple­men­to­wać to jego opra­co­wa­nie to tak­że pro­jek­to­wa­nie. Nadal uwa­żam, że nie jest to robo­ta dla pro­gra­mi­sty, bo na jakiej pod­sta­wie on miał by taki model opracować?

Jak wyglą­da więc pra­ca ana­li­ty­ka biz­ne­so­we­go zgod­nie z mode­lem kom­pe­ten­cyj­nym IIBA (IIBA com­pe­ten­cy model). Kluczowym ele­men­tem pra­cy Analityka Biznesowego (w kon­wen­cji IIBA) jest pro­wa­dze­nie (ana­li­za) wyma­gań od momen­tu okre­śle­nia potrze­by biz­ne­so­wej aż do imple­men­ta­cji uzy­ska­nia wła­ści­we­go roz­wią­za­nia. Jednak uzy­ska­nie to nie to samo co wła­sno­ręcz­ne wyko­na­nie. Znowu ana­lo­gia do budow­nic­twa: archi­tekt na bazie biz­ne­so­wych celów swo­je­go klien­ta opra­co­wu­je nie tyl­ko wizu­ali­za­cję budyn­ku ale tak­że jego kon­struk­cję, do takie­go pozio­mu by deve­lo­per miał jed­no­znacz­nie posta­wio­ne wyma­ga­nia, nie blo­ku­je to jed­nak deve­lo­pe­ro­wi reali­za­cji” wszel­kich poza-funk­cjo­nal­nych wymagań.

Więc po kolei, opracowujemy.

Model procesu biznesowego

Model procesuMamy tu pro­ces skła­da­ją­cy się z dwóch ele­men­tar­nych pro­ce­sów biz­ne­so­wych (czyn­no­ści). Każda czyn­no­ści, zgod­nie z defi­ni­cją pro­ce­su biz­ne­so­we­go, ma dane wej­ścio­we i dane wyj­ścio­we. Dokument 2 i Dokument 3 powsta­ją w tych pro­ce­sach. Mamy tak­że Procedury two­rze­nia doku­men­tów, czy­li jakąś logi­kę ich two­rze­nia. Pojawia się tak­że regu­ła biz­ne­so­wa. Jest to to ele­ment z poza nota­cji BPMN (nota­cja ta zawie­ra jed­nak moż­li­wość ozna­cza­nia czyn­no­ści wyma­ga­ją­cych uży­cia takiej regu­ły). Na dia­gra­mie poka­za­no, regu­łę biz­ne­so­wą oraz jej powią­za­nie z kon­kret­ną czynnością.

Czas zacząć ana­li­zo­wać czy­li pro­jek­to­wać nasz System. Założenie: wyma­ga­ne jest by System (opro­gra­mo­wa­nie) wspie­ra­ło oba pro­ce­sy: 1 i 2 (przy­po­mnę, że pro­ces biz­ne­so­wy to jed­na czyn­ność lub ich sekwen­cja, więc jed­ną czyn­ność mają­cą wej­ście i wyj­ście tak­że z defi­ni­cji, utoż­sa­mia­ny z pro­ce­sem biznesowym).

Usługi systemu

Usługi sys­te­mu to korzeń ana­li­zy obiek­to­wej. Stanowią szkie­let całe­go obiek­to­we­go pro­jek­tu. two­rzy­my bar­dzo waż­ny dia­gram: dia­gram przy­pad­ków użycia.

Usługi systemu

Często sły­szę, że ten dia­gram nic nie wno­si do pro­jek­tu. To nie praw­da. Wnosi klu­czo­wą infor­ma­cję: wyzna­cza gra­ni­ce Systemu i wska­zu­je ewen­tu­al­ne powią­za­nia z inny­mi sys­te­ma­mi. Ale też nie praw­dą jest, że słu­ży do poka­za­nia cze­go­kol­wiek ponad to, np. kolej­no­ści korzy­sta­nia z usług czy struk­tu­ry wewnętrz­nej. To ostat­nie robi­my w posta­ci mode­lu dziedziny.

Na powyż­szym dia­gra­mie udokumentowano:

  1. System ofe­ru­je użyt­kow­ni­ko­wi dwie usłu­gi (to wyma­ga­nie by Czynność 1 i Czynność 2 pro­ce­su były wspie­ra­ne przez System). 
  2. System będzie korzy­stał z danych inne­go opro­gra­mo­wa­nia (Zewnętrznego źró­dła danych), wyma­ga­na jest więc integracja.
  3. Usługa 2 jest reali­zo­wa­na w cało­ści przez inny, zewnętrz­ny sys­tem, wyma­ga­ne jest od sys­te­mu więc by obsłu­gi­wał prze­kie­ro­wa­nie na inny sys­tem (np. reali­za­cja płat­no­ści na stro­nie Banku).

Zakres pro­jek­tu to wyłącz­nie to co w środ­ku”, albo lepiej: wszyst­ko to co jest poza pro­sto­ką­tem System jest poza zakre­sem pro­jek­tu. Nie dostar­cza­my ani Zewnętrznego źró­dła danych ani Systemu Zewnętrznego usłu­go­daw­cy ale musi­my na liście wyma­gań zapi­sać, że inte­gra­cja z nimi jest wyma­ga­na i jaka ona ma być.

Logika działania Systemu – model dziedziny

Zabawa zaczy­na się tu: zamie­nia­my sce­na­riu­sze” na narzę­dzia i materiały”:

Model dziedziny

Celowo zacho­wa­łem nazwy tak by moż­li­we było śla­do­wa­nie” co z cze­go powsta­ło. Kilka komen­ta­rzy, czy­li dobre prak­ty­ki, wzor­ce i styl projektowania.

Każda usłu­ga ma swo­ją dedy­ko­wa­ną kla­sę, zmia­ny reali­za­cji jed­nej nie prze­nio­są się na inne. Usługi są więc od sie­bie nie­za­leż­ne. Oddzielono two­rze­nie doku­men­tów od ich prze­cho­wy­wa­nia, dzię­ki cze­mu łatwo w przy­szło­ści zmie­nić meto­dy ich two­rze­nia bez potrze­by inge­ren­cji w repo­zy­to­rium. Wszelkie regu­ły biz­ne­so­we (w tym vali­da­cji) są zamknię­te” w tak zwa­nych zło­żo­nych typach danych (valueObject, sytu­acja ide­al­na to cał­ko­wi­ty brak typów pro­stych (typy pro­ste, pri­mi­ti­ves) w pro­jek­cie, wyłącz­nie typy zło­żo­ne). W zasa­dzie zastą­pie­nie wszyst­kich typów pro­stych na zło­żo­ne w obsza­rze mode­lu dzie­dzi­ny, otwie­ra w przy­szło­ści dro­gę do ich roz­bu­do­wy bez potrze­by wpro­wa­dza­nia innych zmian w pro­gra­mie. Realnie pomię­dzy Aktorem a usłu­gą ist­nie­ją kla­sy wido­ku (GUI, View w MVC), tu nie umiesz­czo­ne, bo kla­sy te nie reali­zu­ją (nie powin­ny) żad­nej logi­ki biznesowej.

Powyższy model:

  1. Spełnia zasa­dy SOLID (w szcze­gól­no­ści System jest łatwy w roz­sze­rza­niu i nie wyma­ga w tym celu zmian)
  2. Jest zgod­ny z DDD czy­li struk­tu­ra mode­lu odwzo­ro­wu­je struk­tu­rę i poję­cia biznesowe.

Co zysku­je­my? Niskie kosz­ty dal­sze­go roz­wo­ju, łatwość wyce­ny pro­jek­tu przez deve­lo­pe­ra (zna archi­tek­tu­rę). Powstanie takie­go pro­jek­tu daje mi gwa­ran­cję, że panu­je nad nim. Owszem mogę zało­żyć, że deve­lo­per tak­że taki model opra­cu­je, jed­nak życie poka­zu­je, że pra­wie na pew­no nie…

Powyższe z oczy­wi­stych powo­dów (mało miej­sca i uogól­nie­nie) nie zawie­ra szcze­gó­łów, ale te nale­ży zawsze w pro­jek­cie odkła­dać na sam koniec. Dzięki temu może­my sku­pić się na rze­czach na praw­dę waż­nych (waż­ne jest by zro­zu­mieć cel two­rze­nia doku­men­tu a nie spi­sać jego zawar­tość, ta ostat­nia wyni­ka z tego do cze­go służy).

Ostatni wpis na blo­gu, o Niskim pozio­mie ana­li­zy zawie­ra akapit:

Istnieje nie­ste­ty tak­że bar­dzo duże ryzy­ko, któ­re­go źró­dłem jest sto­so­wa­nie sta­rych, struk­tu­ral­nych metod wytwa­rza­nia opro­gra­mo­wa­nia czy­li roz­biór” (i pro­jekt) sys­te­mu na bazę danych i pro­ce­du­ry. Ta prak­ty­ka (meto­da) nie­ste­ty daje jako efekt opro­gra­mo­wa­nie bar­dzo kosz­tow­ne w pro­jek­to­wa­niu i roz­wo­ju. Od metod struk­tu­ral­nych znacz­nie lep­sze są meto­dy obiek­to­we, nie­ste­ty samo dekla­ro­wa­nie korzy­sta­nia z .NET czy Java albo nota­cji UML nie czy­ni sto­so­wa­nych metod obiektowymi.

Właśnie dla­te­go ana­li­za i wyma­ga­nia powin­ny zawie­rać model dzie­dzi­ny wraz z zale­ce­nia­mi co do imple­men­ta­cji. Nie jest to doku­ment (ten model) dla spon­so­ra pro­jek­tu (w rozu­mie­niu do czy­ta­nia). Jego rola (war­tość jaką wno­si do pro­jek­tu) to mini­ma­li­za­cja ryzy­ka, że deve­lo­per wyko­na coś cze­go nie chcemy.

A gdzie baza danych? Nie tu! Implementacja prze­cho­wy­wa­nia danych to pra­ca deve­lo­pe­ra, nie wol­no mu jedy­nie znor­ma­li­zo­wać powyż­sze­go mode­lu. Zaprojektowanie rela­cyj­ne­go mode­lu i uży­cie mapo­wa­nia obiek­to­wo-rela­cyj­ne­go znisz­czy wszyst­kie zale­ty tego pro­jek­tu a dodat­ko­wo strasz­nie skom­pli­ku­je całość.

(prze­druk uka­zał się w ERP-View)