Wymagania biznesowe i Siatka Zachmana

Cztery lata temu pisa­łem o książ­ce Ronalda Rossa Building Business Solutions”:

Druga to pozy­cja nowa, cało­ścio­wo opi­su­ją­ca podej­ście pole­ga­ją­ca na mode­lo­wa­niu orga­ni­za­cji w ana­li­zie biz­ne­so­wej (zawie­ra część mate­ria­łu pierw­szej) . Zwraca uwa­gę na fakt, że nie cho­dzi w ana­li­zie o two­rze­nie mnó­stwa dia­gra­mów a o to, by zro­zu­mieć jak orga­ni­za­cja funk­cjo­nu­je opi­su­jąc to, oraz stwo­rzyć model, któ­ry pozwo­li na pro­gno­zo­wa­nie zacho­wa­nia orga­ni­za­cji w odpo­wie­dzi na bodź­ce, nawet te któ­re jesz­cze nie zaist­nia­ły. (Źródło: Business Rule Concepts ? czy­li jak ?wyłu­skać isto­tę rze­czy? | | Jarosław Żeliński IT-Consulting)

Niedawno wpadł mi w skrzyn­kę kolej­ny wpis na blo­gu R.Rossa:

Zachman?s basic pre­mi­se is that whe­ne­ver you engi­ne­er any­thing of com­ple­xi­ty, no mat­ter what ? a com­plex machi­ne, a sky­scra­per, a micro­chip, a spa­ce­craft, a pro­duct, a busi­ness (an enter­pri­se), or some part of a busi­ness (a busi­ness capa­bi­li­ty) ? the­re are two basic aspects that need to be addres­sed. These two aspects cor­re­spond to the columns and rows of the Framework. (Źródło: What the Zachman Architecture Framework Is ? And How It Relates to Business Rules & Business Analysis | Ronald Ross | LinkedIn, Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edi­tion, by Ronald G. Ross & Gladys S.W. Lam, 2015)

I oka­zu­je się, że zawsze war­to wra­cać do ksią­żek :). Od daw­na pra­cu­je nad uwol­nie­niem spon­so­rów pro­jek­tów od wyma­ga­nia by rozu­mie­li tech­no­lo­gię i teo­rie sys­te­mów. W lite­ra­tu­rze nie raz mozna spo­tkać poję­cie wyma­gań biz­ne­so­wych, pisa­łem o tym trzy lata temu:

Mianem sys­tem okre­śla się zwy­cza­jo­wo spe­cy­fi­ko­wa­ne opro­gra­mo­wa­nie, jed­nak pro­blem poja­wi się natych­miast, gdy dotknie­my takich pojęć jak wyma­ga­nia funk­cjo­nal­ne na opro­gra­mo­wa­nie i wyma­ga­nia biz­ne­so­we. To ostat­nie nie­sie pew­ną nie­ja­sność. Bo nie wiem czy cho­dzi o wyma­ga­nia wobec (w sto­sun­ku do) biz­ne­su (np. popra­wa jako­ści obsłu­gi klien­ta o 5% w naj­bliż­szym bada­niu jako­ści ISO) czy wyma­ga­nia biz­ne­su wobec (w sto­sun­ku do) opro­gra­mo­wa­nia (np. mini­ma­li­za­cja do zera otrzy­ma­nych i zagu­bio­nych zapy­tań ofer­to­wych). (Źródło: Inżynieria wyma­gań | | Jarosław Żeliński IT-Consulting)

Wymieniona wyżej książ­ka Rossa zawie­ra roz­dział Understanding Business Requirements i takie jego sło­wa pod tym tytułem:

RonRossBuildingBusinessSolution_17_1

Model biz­ne­so­wy two­rzy­my by opi­sać daną dzia­łal­ność, może być on tak­że uży­ty do stwo­rze­nia wyma­gań biz­ne­so­wych.” Nieco dalej czytamy:

RonRossBuildingBusinessSolution_17_2

Bardzo waż­ne: wyma­ga­nia biz­ne­so­we defi­niu­je­my wobec sys­te­mu a nie wobec biz­ne­su (fir­my). I to fak­tycz­nie jest powo­dem wie­lu nie­po­ro­zu­mień. W tym samym roz­dzia­le Ross powo­łu­jąc się na Siatkę Zachmana przy­wo­łu­je definicje:

RonRossBuildingBusinessSolution_17_3

Od dłuż­sze­go cza­su sto­su­ję w pro­jek­tach poję­cie Wymagań Biznesowych (opi­sa­ne w cyto­wa­nym wyżej, moim arty­ku­le Inżynieria wyma­gań), i po raz kolej­ny zno­wu, skła­niam się do pró­by wyko­rzy­sta­nia siat­ki Zachmana w tym celu, gdyż jeże­li ten szkie­let archi­tek­to­nicz­ny (Siatka Zachmana to tak zwa­ny szkie­let archi­tek­to­nicz­ny archi­tek­tu­ry kor­po­ra­cyj­nej) fak­tycz­nie pozwo­li spraw­nie zarzą­dzać wyma­ga­nia­mi i ich śla­do­wa­niem, to war­to z tego sko­rzy­stać, na razie porów­nu­je się (nakła­da się) ten szkie­let z MDA i jak widać jest świa­teł­ko w tunelu :):

MDA2Zachman

Dla uła­twie­nia siat­ka Zachmana w pol­skiej wer­sji (kard z pakie­tu Visual-Paradigm).

Siatka Zachmana zakres analizy

Koncepcja to nie wymagania!

Dwa lata temu pisa­łem o tym, czym jest, po co się pro­wa­dzi i jak, stu­dium wyko­ny­wal­no­ści projektu:

W lite­ra­tu­rze moż­na spo­tkać róż­ne ?defi­ni­cje? stu­dium wyko­nal­no­ści, jed­nak ta któ­rą opi­sa­łem, zda­je się być naj­bliż­sza defi­ni­cji, któ­rą przy­to­czy­łem na począt­ku: bazu­ją­cej na zna­cze­niu słow­ni­ko­wym. Praktyka poka­zu­je, że inten­cje spon­so­rów tych ana­liz są z nią zbież­ne: celem jest pod­ję­cie decy­zji o naj­mniej­szym ryzy­ku w świe­tle posia­da­nej na dany temat wie­dzy. Definicje bazu­ją­ce na tech­nicz­nej i finan­so­wej wyko­nal­no­ści dane­go pro­jek­tu, są spo­ty­ka­ne dość czę­sto i w lite­ra­tu­rze i na stro­nach wie­lu insty­tu­cji. Metoda pro­wa­dze­nia takich ana­liz, bazu­ją­ca na mode­lo­wa­niu czy­li na ana­li­zie sys­te­mo­wej, wyda­je się być jed­nak naj­wła­ściw­szą. (Źródło: Studium wyko­nal­no­ści ? czym napraw­dę jest | | Jarosław Żeliński IT-Consulting)

W arty­ku­le tym zwra­ca­łem uwa­gę na war­tość mode­lo­wa­nia (a nie ryso­wa­nia…), war­to­ścią tą jest testo­wa­nie kon­cep­cji. Sama kon­cep­cja nie jest żad­nym wyma­ga­niem, co ilu­stru­je świet­ny arty­kuł na stro­nach Modernanalyst​.com:

Requirements must be based on facts and real-life sce­na­rios. When the con­cept is unte­sted or not ful­ly tested, then the requ­ire­ments are hypo­the­ti­cal. Moving to design and build with hypo­the­ti­cal requ­ire­ments, the design and/or build pha­se beco­mes the testing gro­und for the con­cept. This may lead to cla­shes as each par­ty has dif­fe­rent expec­ta­tions of the out­co­me of the ?hypo­the­ses?.

Źródło: Blueprints Are Not Requirements!

Powyższy dia­gram poka­zu­je głów­ne prze­sła­nie opi­sa­nej meto­dy, któ­ra jest zgod­na w 100% z peł­ną ana­li­zą sys­te­mo­wą: pierw­szy etap to opra­co­wa­nie kon­cep­cji czy­li hipo­te­zy mówią­cej taki sys­tem jest nam potrzeb­ny” do roz­wią­za­nia pro­ble­mu biz­ne­so­we­go (potrze­by biz­ne­so­we). Kolejny etap to stwier­dze­nie popraw­no­ści pomy­słu, to nic inne­go jak stu­dium wyko­nal­no­ści, testo­wa­nie pomy­słu. Tu waż­na rzecz: test musi być pro­wa­dzo­ny w opar­ciu o fak­ty i tyl­ko fak­ty, inny­mi sło­wy model nie może koli­do­wać z rze­czy­wi­sto­ścią, musi tak­że poka­zać, że zapro­jek­to­wa­ny nowy lub zmie­nio­ny mecha­nizm dzia­ła­nia orga­ni­za­cji da ocze­ki­wa­ne efek­ty. Dopiero gdy hipo­te­za mówią­ca, że taki sys­tem reali­zu­je nasze potrze­by” zosta­nie potwier­dzo­na testa­mi na mode­lu, ma sens opra­co­wy­wa­nie wyma­gań na to roz­wią­za­nie. W toku opra­co­wy­wa­nia wyma­gań, tak­że je testu­je­my. Tu zno­wu spraw­dza się sku­tecz­ność podej­ścia pro­jekt (model) jako wymaganie”.

Trzy lata temu opi­sa­łem cały taki pro­ces, na dość może try­wial­nym przy­kła­dzie (sza­chy), ale za to (mam nadzie­ję) przej­rzy­stym. Na zakoń­cze­nie arty­ku­łu zwró­ci­łem uwa­gę, że:

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko ?imple­men­ta­cja? kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakaś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję poka­za­łem. Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kur­sów. (Źródło: Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie | | Jarosław Żeliński IT-Consulting).

Autor arty­ku­łu przy­wo­łu­je nie­zmien­ną od lat statystykę:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

…i zwra­ca uwa­gę, że ich przy­czy­ny są od lat sta­le takie same…

Requirements must be based on facts and real-life sce­na­rios.” (wyma­ga­nia muszą być opar­te na fak­tach i real­nych sce­na­riu­szach). Więc ile war­te są wizje w pro­jek­tach agi­le albo wydu­ma­ne w toku warsz­ta­to­wych burz mózgów lita­nie życzeń i pomy­słów? Nie tyl­ko moim zda­niem: nie są wie­le war­te i nie powin­ny być wymaganiami.

TDD – czy same testy to wymagania?

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

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

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

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

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

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

Niedawno pisa­łem:

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

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

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

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

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

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

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

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

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

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

Zilustrować to moż­na tak:

Wymagania

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

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

Paradygmat i metody obiektowe

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

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

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

Co to jest Test Driven Development

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

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

Źródło: Test Driven Development

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

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

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

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

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

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

Na zakończenie

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

Wymagania ? Zarządzanie wersjami

Pomijając ich warian­ty, sto­so­wa­ne są dwie meto­dy (gru­py metod) doku­men­to­wa­nia wyma­gań i zarzą­dza­nia nimi. Zakładamy, że są to wyma­ga­nia wobec pro­duk­tu (roz­wią­za­nia) jaki ma dostar­czyć jego dostaw­ca. W BABoK (Business Analysis Body of Knowledge), wyma­ga­nia te musi speł­nić dostar­czo­ny pro­dukt, jed­nak oczy­wi­ście roz­li­cza­ny jest dostaw­ca rozwiązania.

Stosowane są trzy meto­dy (gru­py metod) spe­cy­fi­ko­wa­nia wymagań:

  1. Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych (i warian­ty tej metody).
  2. Specyfikowanie tak zwa­nej czar­nej skrzyn­ki” (przy­pad­ki użycia).
  3. Specyfikowanie tak zwa­nej bia­łe skrzyn­ki” (przy­pad­ki uży­cia + model dzie­dzi­ny systemu).

Pierwsza i naj­star­sza meto­da bazu­je na zało­że­niu, że zama­wia­ją­cy i (lub) przy­szły użyt­kow­nik wie cze­go chce. Wymagania w posta­ci listy (funk­cjo­nal­ne i poza-funk­cjo­nal­ne) kolek­cjo­no­wa­ne są na warsz­ta­tach, burzach mózgów, tak zwa­nych sesjach JAD (ang. [[Joint Application Development]]), bywa, że z pomo­cą ankiet. Powstaje lista (tabe­la) z odpo­wied­nio ozna­czo­ny­mi i skla­sy­fi­ko­wa­ny­mi wymaganiami.

Czarna skrzyn­ka” to wyma­ga­nia opra­co­wa­ne w posta­ci opi­su roz­wią­za­nia sku­pia­ją­ce­go się wyłącz­nie na jego zewnętrz­nych cechach, zmu­sza do wyspe­cy­fi­ko­wa­nia tego do cze­go ma ono słu­żyć, jed­nak nie opi­su­je mecha­ni­zmu jego dzia­ła­nia, spe­cy­fi­ka­cja przy­pad­ków uży­cia w zasa­dzie zamy­ka się na udo­ku­men­to­wa­niu bodź­ca i efek­tu (stan począt­ko­wy i koń­co­wy) każ­de­go przy­pad­ku uży­cia (usłu­gi spe­cy­fi­ko­wa­nej apli­ka­cji), wyja­śnie­nie np. spo­so­bu wyko­na­nia obli­czeń – owszem – doku­men­to­wa­ne jest w posta­ci np. wzo­rów mate­ma­tycz­nych czy algo­ryt­mów, jed­nak taka cecha jak np. moż­li­wość sko­ja­rze­nia wszyst­kich zamó­wień, na bazie któ­rych powsta­ła zbior­cza fak­tu­ra na koniec mie­sią­ca” pozo­sta­je tyl­ko nazwa­nym wyma­ga­niem, spe­cy­fi­ka­cja taka nie zawie­ra opi­su mecha­ni­zmu pozwa­la­ją­ce­go na taka operację.

Biała skrzyn­ka” to spe­cy­fi­ka­cja jak wyżej, uzu­peł­nio­na o opis (model) np. mecha­ni­zmu pozwa­la­ją­ce­go na sko­ja­rze­nie tych zamó­wień z wła­ści­wą fakturą.

BABoK gene­ral­nie wska­zu­je (sku­pia się) na dwóch ostat­nich metodach.

W każ­dym pro­jek­cie trwa­ją­cym w cza­sie i dopusz­cza­ją­cym zmia­ny w jego zakre­sie (w wyma­ga­niach) poja­wia się potrze­ba zarzą­dza­nia zmia­na­mi, zaspo­ka­ja­na prak­tycz­nie zawsze z pomo­cą tak zwa­ne­go wer­sjo­no­wa­nia. Wersjonowanie wyma­gań w posta­ci pła­skiej listy wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych, jest żmud­ne, spro­wa­dza się do nie­za­leż­ne­go wer­sjo­no­wa­nia tre­ści (brzmie­nia) każ­de­go wyma­ga­nia wraz z moż­li­wo­ścią poja­wie­nia się nowe­go i usu­nię­cia już ist­nie­ją­ce­go (lub nada­nia mu sta­tu­su odrzu­co­ne”). Opisał to ład­nie Miał Wolski:

Zmiany w wyma­ga­niach wyma­ga ich wer­sjo­no­wa­nia. Wersje wyma­gań poma­ga­ją uzy­skać dostęp do okre­ślo­ne­go sta­nu wyma­ga­nia w trak­cie życia opro­gra­mo­wa­nia. Najczęściej wer­sje wyma­gań okre­śla­ne są za pomo­cą kolej­nych ich nume­rów. Najbardziej popu­lar­nym spo­so­bem nada­wa­nia nume­rów wyma­gań jest zło­że­nie nume­ru z wer­sji wyma­ga­nia oraz przy­ro­stu, oddzie­lo­nych zna­kiem krop­ki. Wersja 1.3 ozna­cza wte­dy 1 wer­sję wyma­ga­nia i 3 przy­rost. (Źródło: Wymagania ? Zarządzanie wer­sja­mi | Michał Wolski)

Zupełnie ina­czej wyglą­da w pozo­sta­łych dwóch meto­dach. Zarówno czar­na skrzyn­ka” jak i jej bia­ła” odmia­na, to są już pro­jek­ty roz­wią­za­nia (np. apli­ka­cji), bia­ła skrzyn­ka” zawie­ra wewnętrz­ną archi­tek­tu­rę. Wobec tego jest to jeden pro­jekt” a nie np. czte­ry­sta wyma­gań”. Wersjonowaniu pod­le­ga tu jeden pro­jekt, dzię­ki temu sam pro­ces wer­sjo­no­wa­nia i zarzą­dza­nie nim sta­je się znacz­nie prost­szy (moż­na to robić np. z pomo­cą sys­te­mów zarzą­dza­nia wer­sja­mi taki­mi jak [[CVS]], [[SVR]] itp.). Owszem, pro­jekt może zawie­rać wie­le deta­li, żeby uła­twić zna­le­zie­nie róż­ni­cy mię­dzy wer­sja­mi (tego co zosta­ło wła­śnie zmie­nio­ne) na począt­ku doku­men­tu (spe­cy­fi­ka­cji pro­jek­tu) umiesz­cza się tak zwa­ny regestr zmian (doty­czy całe­go projektu).

Opracowanie listy wyma­gań funk­cjo­nal­nych i poza funk­cjo­nal­nych jest rela­tyw­nie naj­prost­sze, nie wyma­ga od pra­cow­ni­ków zama­wia­ją­ce­go dodat­ko­wych kwa­li­fi­ka­cji, mogą w tym pro­ce­sie brać udział przy­szli użyt­kow­ni­cy, jed­nak utrzy­ma­nie kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji jest najtrudniejsze.

W przy­pad­ku skrzy­nek” już sam fakt, że są one pro­jek­tem (pew­ną kon­struk­cją) pozwa­la sto­so­wać do ich opi­su typo­we inży­nier­skie meto­dy takie jak mode­lo­wa­nie. Model moż­na testo­wać więc zagwa­ran­to­wa­nie spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści jest łatwiej­sze, pro­ble­mem pozo­sta­je co naj­wy­żej kom­plet­ność, czy­li odpo­wiedź na pyta­nie Czy to są wszyst­kie wyma­ga­ne funk­cje”. Ryzyko jakie stwa­rza czar­na skrzyn­ka” to pozo­sta­wie­nie dostaw­cy (wyko­naw­cy, deve­lo­pe­ro­wi) decy­zji o posta­ci mecha­ni­zmu dzia­ła­nia (jego zapro­jek­to­wa­nie). Dostawca może go zbyt upro­ścić lub wręcz nie rozu­mieć i powsta­nie coś co nie reali­zu­je w 100% logi­ki biz­ne­so­wej danej orga­ni­za­cji. Biała skrzyn­ka” niwe­lu­je to ryzy­ko: powsta­je tu pro­jekt wewnętrz­nej logi­ki: mecha­nizm dzia­ła­nia aplikacji.

Konsekwencje. Wydawało by się, że pierw­sza meto­da jest naj­tań­sza, bo pro­jek­to­wa­nie jest kosz­tow­niej­szą pra­cą bo wyma­ga znacz­nie więk­szych kom­pe­ten­cji niż pro­wa­dze­nie warsz­ta­tów, sam przy­szły użyt­kow­nik z regu­ły nie posia­da tych kom­pe­ten­cji i musi za nie zapła­cić. Niestety jest to praw­da dla małych pro­jek­tów, tam gdzie poja­wia­ją się wyma­ga­nia w ilo­ści setek i nie raz tysię­cy, samo zarzą­dza­nie nimi jest tak pra­co­chłon­ne, że koszt rośnie szyb­ciej niż licz­ba tych wymagań.

Po prze­kro­cze­niu pew­ne­go pozio­mu zło­żo­no­ści znacz­nie lep­sze są meto­dy sys­te­mo­we opar­te na pro­jek­to­wa­niu („skrzyn­ki”), i tu waż­na uwa­ga: pro­jek­to­wa­nie to etap spe­cy­fi­ko­wa­nia wyma­gań, jeże­li pro­jekt opra­cu­je zama­wia­ją­cy, niwe­lu­je ryzy­ka jakie nie­sie ze sobą zle­ce­nie pro­jek­to­wa­nia deve­lo­pe­ro­wi: praw­do­po­dob­nie będzie uprasz­czał pro­jekt (obni­żał swój koszt) i bar­dzo praw­do­po­dob­ne, że będzie for­so­wał swo­je dotych­cza­so­we doświad­cze­nie z fir­my o podob­nym cha­rak­te­rze co nie­ste­ty bar­dzo czę­sto pro­wa­dzi do nie­upraw­nio­ne­go powie­le­nie cudzej i nie­ko­niecz­nie dobrej, logi­ki biz­ne­so­wej. Do tego poja­wia się pro­blem (duże ryzy­ko) zawłasz­cze­nia przez dostaw­cę praw autor­skich do pro­jek­tu tej biz­ne­so­wej logi­ki i całe­go mecha­ni­zmu dzia­ła­nia apli­ka­cji a tym samym orga­ni­za­cji (o czym nie raz tu już pisa­łem).

Nieprzewidywalne wymagania

Właśnie, jak to jest? Regularnie sły­szę z ust zwo­len­ni­ków sto­so­wa­nia meto­dy, któ­rą nazy­wa­ją zwin­ną”, że nie da się opi­sać wyma­gań przed roz­po­czę­ciem pro­jek­tu, należy/można je [wyma­ga­nia] odkry­wać w toku pro­jek­tu, bo klient zna tyl­ko cel i razem do nie­go dąży­my, pro­to­ty­py – tak wła­śnie radzi­my sobie z nie­prze­wi­dy­wal­no­ścią wymagań”.

Przypomnę: wyma­ga­nia to warun­ki jakie coś musi speł­nić aby było przy­dat­ne” (sł. j.polskiego PWN), jak mam tu rozu­mieć brak wyma­gań na począt­ku pro­jek­tu”, sko­ro jego – pro­jek­tu – celem jest wytwo­rze­nie cze­goś przy­dat­ne­go? Co to zna­czy wyma­ga­nia dzi­siaj są nie­prze­wi­dy­wal­ne”? To zna­czy chy­ba tyl­ko to, że zama­wia­ją­cy kom­plet­nie nie ma poję­cia po co roz­po­czy­na pro­jekt! (Co nie raz nie­ste­ty bywa prawdą).

Niedawno mia­łem kolej­ne spo­tka­niu z pew­ny­mi deve­lo­pe­ra­mi” i co mogę po nim powie­dzieć? Otóż war­to się uczyć i czy­tać, bo wte­dy Ci ludzie, wie­dzie­li by, że nie nale­ży mylić wyma­gań z cecha­mi roz­wią­za­nia (doty­czy to tak­że zama­wia­ją­cych i nama­wiam ich do korzy­sta­nia z usług pro­fe­sjo­na­li­stów) i źle jest, gdy ktoś taki (nie dostrze­ga­ją­cy tych róż­nic) robi wodę z mózgu nabyw­com opro­gra­mo­wa­nia. Prawdą jest, że sko­ro nie powsta­ło roz­wią­za­nie, to nie zna­my wszyst­kich jego cech i odkry­je­my je (powsta­ną) w toku prac nad jego two­rze­niem. Nie praw­dą jest jed­nak, że nie zna­my wyma­gań na począt­ku pro­jek­tu z powo­dów jak powy­żej, a jeże­li fak­tycz­nie ich nie zna­my, to co i po co robi­my?! (i to jest pyta­nie do tych, któ­rzy zama­wia­ją oprogramowanie!).

Warto więc poznać trosz­kę tej wstręt­nej, nie mają­cej nic wspól­ne­go z prak­ty­ką”, teo­rii co pozwo­li lepiej się komu­ni­ko­wać i nie wci­skać niko­mu kitu, zaś w kwe­stii pro­ste­go słow­nic­twa typy, wyma­ga­nie czy cecha, gorą­co pole­cam po pro­stu pozna­nie ojczy­ste­go języka… 😉

Requirements Engineering ActivitiesGeneralnie wyma­ga­niem (nazy­wam je biz­ne­so­wym”) jest pomysł lub ocze­ki­wa­nie biz­ne­su”, np. sys­tem ma uspraw­nić obsłu­gę zapy­tań ofer­to­wych”, sys­tem ma pozwa­lać na archi­wi­zo­wa­nie wszyst­kich zapy­tań i ofert w spo­sób pozwa­la­ją­cy na łatwe dotar­cie do każ­de­go doku­men­tu”, itp. (to praw­dzi­we zapi­sy z pew­ne­go pro­jek­tu). Są wyma­ga­nia? Są! Co teraz? Popatrzmy na kla­sycz­ny” tok ana­li­zy spe­cy­fi­ko­wa­nia wyma­gań po pra­wej stro­nie. taki dia­gram moż­na zoba­czyć na nie­mal­że każ­dym szko­le­niu z tego zakre­su, jed­nak na mało któ­rym, usły­szy­cie jak prze­pro­wa­dzić ową wali­da­cję” (sł j.polskiego: wali­da­cja ?ogół czyn­no­ści mają­cych na celu zba­da­nie odpo­wied­nio­ści, traf­no­ści lub dokład­no­ści czegoś?). 

Sam prze­gląd wyma­gań nic nie daje, one mają być spój­ne, kom­plet­ne i nie­sprzecz­ne. Sam prze­gląd pozwo­li co naj­wy­żej spraw­dzić spój­ność i nie­sprzecz­ność, a kom­plet­ność? Właśnie po to się robi ana­li­zę pro­ce­sów: two­rzy­my model dzia­ła­nia fir­my, by po pierw­sze upew­nić się, że wie­my i rozu­mie­my jak ona dzia­ła, a potem na tej pod­sta­wie oce­nić, czy wyma­ga­nia są kom­plet­ne (zakres pro­jek­tu, czy­li wyma­ga­nia, fak­tycz­nie obej­mu­ją wszyst­kie te dzia­ła­nia fir­my, któ­re chce­my by były nim objęte).

Tak więc moż­na nie znać szcze­gó­łów przy­szłe­go pro­duk­tu i pro­jek­tu zara­zem, w koń­cu powsta­je on – jego kolej­ne cechy – np. ite­ra­cyj­nie, ale całość, jako pro­jekt, powin­na być zna­na w kwe­stii do cze­go ma to słu­żyć i jak”. Nikt roz­sąd­ny nie podej­mie się budo­wy wie­żow­ca, nie mając poję­cia ile doce­lo­wo ma mieć pie­ter i do cze­go posłu­ży każ­de z nich… na pałę to zbi­ja­my raczej budę dla psa lub sto­do­łę (cyt. E.Yourdon ;)), ale fak­tycz­nie nie ma sen­su szcze­gó­ło­we pla­no­wa­nie wystro­ju wnętrz przed zakoń­cze­niem budo­wy całej konstrukcji.

Tu więc tak­że rada dla zama­wia­ją­cych opro­gra­mo­wa­nie: kom­plet­nie pozba­wio­ne sen­su jest pisa­nie na począt­ko­wym eta­pie ana­li­zy wyma­gań cze­goś w rodza­ju sys­tem, pod­czas wysta­wia­nia fak­tu­ry, powi­nien pozwa­lać na wybór, z roz­wi­ja­nej listy uru­cha­mia­nej pra­wym kla­wi­szem myszy, listy kon­tra­hen­tów i pro­duk­tów” (to tak­że cytat z pew­nej spe­cy­fi­ka­cji). Jest to zupeł­nie nie­upraw­nio­na i przed­wcze­sna pró­ba pro­jek­to­wa­nia roz­wią­za­nia. Po pierw­sze są inne meto­dy pod­po­wia­da­nia na ekra­nie, po dru­gie, kon­tra­hent i pro­duk­ty mogą się np. pod­po­wia­dać z tre­ści, wcze­śniej wpro­wa­dzo­ne­go, zamó­wie­nia. po trze­cie jest jesz­cze masa innych moż­li­wych roz­wią­zań i wybór naj­lep­sze­go to rola pro­jek­tan­ta developera.

W tym momen­cie, na zakoń­cze­nie, pole­cam arty­kuł z ubie­głe­go roku, gdzie opi­sa­łem tak­so­no­mię wyma­gań: Produkty w pro­ce­sie ana­li­zy wyma­gań.

____

(doda­ne po pyta­niu czytelnika)

[czy­tel­nik] Jak radzić sobie z wyma­ga­nia­mi, któ­re poja­wia­ją się w trak­cie reali­za­cji projektu?

[autor] Po dobrze prze­pro­wa­dzo­nej ana­li­zie jest ich na praw­dę mało. Z racji tego, że mogą się jed­nak poja­wić, war­to przed roz­po­czę­ciem reali­za­cji pro­jek­tu opi­sać i zatwier­dzić z klien­tem, pro­ce­du­rę zarzą­dza­nia zmia­ną zakre­su pro­jek­tu (któ­ry bywa nie raz załącz­ni­kiem do umo­wy), klient powi­nien czuć cię­żar takich zmian. Dobrą prak­ty­ką jest tak­że, by zakre­sem pro­jek­tu (wpro­wa­dza­niem zmian do spe­cy­fi­ka­cji wyma­gań) zarzą­dzał ktoś trze­ci, nie będą­cy ani zama­wia­ją­cym ani wyko­naw­cą, z uwa­gi na kon­flik­ty inte­re­sów (zama­wia­ją­cy ma ten­den­cje do posze­rza­nia zakre­su bez zwięk­sza­nia budże­tu a wyko­naw­ca dokład­nie odwrot­nie), pole­cam by autor wyma­gań był oso­bą z zewnątrz, i jako trze­cia stro­na, spra­wo­wał tak zwa­ny nad­zór autor­ski, wte­dy sta­je się przy oka­zji media­to­rem przy pró­bach wpro­wa­dza­nia zmian (to spraw­dzo­na meto­da w bran­ży budow­la­nej i nie tylko).

Jeżeli jed­nak zakres pro­jek­tu nie ist­nie­je, to oba­wiam się, że nie ma na to: odkry­wa­nie wyma­gań w toku pro­jek­tu, sposobu.

Wymagania pozafunkcjonalne – integracja

Temat inte­gra­cji prze­wi­ja się nie­mal­że w każ­dym wdro­że­niu. W wyma­ga­niach naj­czę­ściej widu­ję opis tego, jakie dane są wymie­nia­ne, bar­dzo rzad­ko widu­ję dodat­ko­we ogra­ni­cze­nia, w szcze­gól­no­ści chro­nią­ce kupu­ją­ce­go przez duży­mi kosz­ta­mi utrzy­ma­nia. Kupujący jako laik”, szcze­gól­nie sam piszą­cy wyma­ga­nia, prak­tycz­nie nie jest w sta­nie się obro­nić przed taki­mi kosz­ta­mi, a kry­te­rium niskiej ceny przy wybo­rze, prak­tycz­nie zawsze dopro­wa­dzi do przy­szłych kło­po­tów. Dlatego po raz kolej­ny piszę: spe­cy­fi­ka­cja wyma­gań powin­na zawie­rać pro­jekt roz­wią­za­nia, wte­dy nie­ja­ko zabro­ni­my” sto­so­wa­nia szko­dli­wych” roz­wią­zań przez dostaw­cę opro­gra­mo­wa­nia. Większość dostaw­ców opro­gra­mo­wa­nia zawsze będzie szła na skróty.

W poprzed­nim arty­ku­le pisa­łem o wyma­ga­niach poza­funk­cjo­nal­nych, doty­czą­cych kupo­wa­ne­go opro­gra­mo­wa­nia (Wymagania poza­func­kjo­nal­ne czy­li jaka archi­tek­tu­ra), dzi­siaj o inte­gra­cji z innymi.

Niestety sta­le obser­wu­ję podej­ście dostaw­ców opro­gra­mo­wa­nia (tak­że wewnętrz­ne dzia­ły IT!), bazu­ją­ce na moż­li­wie niskim kosz­cie i cza­sie wyko­na­nia inte­gra­cji (budo­wa­nie mar­ży, oszczęd­no­ści cza­su, nie raz nie­wie­dza) przy kom­plet­nym igno­ro­wa­niu tego, że przy­szłe kosz­ty utrzy­ma­nia są wie­lo­krot­nie więk­sze niż te oszczęd­no­ści, a nie raz tra­ci się nawet pano­wa­nie nad zło­żo­no­ścią posia­da­ne­go sys­te­mu (z per­spek­ty­wy dostaw­cy jest to zwy­kłe uza­leż­nia­nie klien­ta i gene­ro­wa­niu mu kosz­tów). Znam przy­pad­ki, w któ­rych źle (czy­taj złą meto­dą, bo trans­fer danych dzia­łał) wyko­na­ne kolej­ne inte­gra­cje nowych apli­ka­cji, dopro­wa­dzi­ły do sytu­acji, w któ­rej prak­tycz­nie nie był moż­li­wy, bez bar­dzo duże­go ryzy­ka kra­chu cało­ści, upgra­de żad­ne­go z pod­sys­te­mów! (w jed­nym z przy­pad­ków to nie była mała fir­ma, to był jeden z więk­szych ope­ra­to­rów sie­ci CATV).

Ale po kolei…

Wzorzec architektoniczny integracji – fasada/adapter

Architektura opro­gra­mo­wa­nia sto­su­ją­ce­go wzo­rzec fasa­dy (tu API) do inte­gra­cji wyglą­da tak:

Architektura integracji

Mamy tu dwie apli­ka­cje: Aplikacja 1 i Aplikacja 2. Każda ma jakąś logi­kę i jakiś skład danych (sys­tem utrwa­la­nia, celo­wo nie piszę baza danych, bo może to być tak­że sys­tem pli­ków). Tak zwa­ne [[API]] to kom­po­nent zapew­nia­ją­cy sepa­ra­cję wnę­trza apli­ka­cji od jej oto­cze­nia i bez­piecz­ne udo­stęp­nie­nie okre­ślo­nych ope­ra­cji (z regu­ły para­me­try­zo­wal­nych), któ­re moż­na z zewnątrz wywo­ły­wać, żąda­jąc pobra­nia lub zacho­wa­nia jakichś infor­ma­cji. Na zewnątrz API udo­stęp­nia Interfejs Oferowany (lizak w nota­cji UML powy­żej). Interfejs Wymagany (kie­li­szek w nota­cji UML powy­żej) to spe­cy­fi­ka­cja tego, cze­go potrze­bu­je apli­ka­cja. Innymi sło­wy Interfejs ofe­ro­wa­ny to funk­cjo­nal­no­ści (usłu­gi) jakie ofe­ru­je apli­ka­cja, inter­fejs wyma­ga­ny to nasze wyma­ga­nia wobec apli­ka­cji (nale­ży je zde­fi­nio­wać w toku ana­li­zy wymagań).

Na dia­gra­mie przy­pad­ków uży­cia inter­fejs ofe­ro­wa­ny to przy­pad­ki uży­cia a inter­fejs wyma­ga­ny to aktor i jego ocze­ki­wa­nia (dia­gram kom­po­nen­tów i odpo­wia­da­ją­cy mu dia­gram przy­pad­ków użycia):

Model komponenrtów - integracja
Model przypadków użycia - integracja

(wię­cej na temat sto­so­wa­nia dia­gra­mów przy­pad­ków uży­cia w kon­tek­ście inte­gra­cji w arty­ku­le o przy­pad­kach uży­cia i gra­ni­cy sys­te­mu)

Jak dopro­wa­dzić do przy­szłe­go kra­chu systemu

Otóż, jak wspo­mnia­łem, czę­stą prak­ty­ka jest dro­ga na skró­ty”, przez nie­któ­rych nazy­wa­na spa­wa­niem apli­ka­cji”. Wygląda to tak:

Częste praktyki

W Aplikacji 1 doda­je się kil­ka bez­po­śred­nich odwo­łań do bazy danych Aplikacji 2, by pobrać dane, któ­re są potrzeb­ne. Efekt tego podej­ścia to cał­ko­wi­te uza­leż­nie­nie dzia­ła­nia Aplikacji 1 od jakich­kol­wiek zmian w struk­tu­rze danych Aplikacji 2. Każda taka zmia­na w Aplikacji 2 (np. jej upda­te czy upgra­de) rodzi ryzy­ko błę­dów w tej wymia­nie danych (inte­gra­cja prze­sta­nie dzia­łać). Stosowanie tablic pośred­nich chro­ni wyłącz­nie przed nie­umyśl­nym naru­sze­niem inte­gral­no­ści danych. Kolejna poważ­na wada tej meto­dy to wymóg, by obie apli­ka­cje pra­co­wa­ły na jed­nym ser­we­rze lub w jed­nej sie­ci lokal­nej. Tak więc każ­da przy­szła ini­cja­ty­wa zwią­za­na np. z pra­cą w sie­ci roz­le­głej (prze­nie­sie­nie z jed­ne­go do inne­go oddzia­łu, przej­ście do chmu­ry itp.) nie ma tu racji bytu (sto­so­wa­nie sie­ci VPN w sie­ciach roz­le­głych to bar­dzo zawod­ny pomysł, wyma­ga­ją­cy bar­dzo kosz­tow­nych łączy).

Ta meto­da ma jesz­cze inną poważ­ną i bar­dziej ukry­tą” wadę. Logika biz­ne­so­wa (regu­ły biz­ne­so­we) raczej tkwi” poza bazą danych (tu Logika apli­ka­cji 2), w efek­cie pobie­ra­nie infor­ma­cji bez­po­śred­nio z bazy danych (System utrwa­la­nia 2) rodzi powa­ża­ne ryzy­ko, że pobra­ne dane będą szko­dli­we”, gdyż pobie­ra­nie ich z pomi­nię­ciem reguł biz­ne­so­wych, powo­du­je, że sens i cel imple­men­ta­cji tych reguł zosta­je zaprzepaszczony.

Jeżeli nasza aplikacja nie ma API

Nie raz mamy do czy­nie­nia ze sta­ry­mi” apli­ka­cja­mi ([[lega­cy sys­tem]]). Wtedy trze­ba API po pro­stu zapro­jek­to­wać i napi­sać. Powinien to zro­bić dostaw­ca apli­ka­cji, z któ­rą się inte­gru­je­my: jemu przed­sta­wia­my spe­cy­fi­ka­cję Interfejsu Wymaganego (I_Żądany1):

Stare aplikacje

Gdyby wymia­na danych odby­wa­ła się w obu kie­run­kach, two­rzo­ny adap­ter dodat­ko­wo pośred­ni­czy w pobie­ra­niu danych z Aplikacji 1.

Na zakończenie

Integracja to jeden z trud­niej­szych pro­ble­mów. Wymaga bowiem nie tyl­ko spe­cy­fi­ko­wa­nia (i potem ich imple­men­to­wa­nia) inter­fej­sów, ale tak­że ana­li­zy i opra­co­wa­nia bez­piecz­nej archi­tek­tu­ry całe­go sys­te­mu (tu zno­wu archi­tek­tu­ra kor­po­ra­cyj­na). Wiele firm ma, nie dwie ale kil­ka, kil­ka­na­ście a nie­któ­re nawet set­ki apli­ka­cji. Jeżeli będę ze sobą pospa­wa­ne” wywo­ła­nia­mi SQL/ODBC, to rusze­nie tego” prak­tycz­nie zawsze koń­czy się kra­chem (czy­taj ogrom­ne kosz­ty przy­wró­ce­nia funk­cjo­no­wa­nia cało­ści). Brak prze­my­śla­nej archi­tek­tu­ry, inte­gra­cja ad-hoc każ­dy z każ­dym”, to pro­sta dro­ga do kło­po­tów i ogrom­nych kosz­tów utrzy­ma­nia cało­ści. Stosowanie API (ich two­rze­nie) nie­co tyl­ko pod­no­si kosz­ty wdro­że­nia, za to chro­ni przed bar­dzo duży­mi, nie­pla­no­wa­ny­mi, wydat­ka­mi w przy­szło­ści. Wielu dostaw­ców opro­gra­mo­wa­nia ofe­ru­je w swo­ich pro­duk­tach API, wystar­czy z nich korzystać.

Dedykowane dzie­dzi­no­we apli­ka­cje coraz czę­ściej są wdra­ża­ne eta­pa­mi zamiast jed­ne­go duże­go ERP, taka inte­gra­cja nie jest wbrew pozo­rom kosz­tow­na, kosz­tow­ny jest brak sto­so­wa­nia dobrych prak­tyk i wzor­ców, któ­re war­to poznać. Zwinność dzia­ła­nia dzi­siej­szych firm na ryn­ku to wymóg a nie opcja. Zwinność taka to nie jeden duży ERP (mono­pol jed­ne­go usłu­go­daw­cy), to kil­ka zin­te­gro­wa­nych, dedy­ko­wa­nych nie­za­leż­nych apli­ka­cji , wdra­ża­nych bez kasto­mi­za­cji (wybie­ra­my naj­lep­szy pro­dukt w danym momen­cie). Ich (apli­ka­cje dzie­dzi­no­we) wymia­na na inne, przy dobrze wyko­na­nej inte­gra­cji, to jest pro­ces, któ­ry nie gene­ru­je mon­stru­al­nych kosz­tów każ­do­ra­zo­wej ana­li­zy i prze­rób­ki cało­ści IT (kolej­nej kasto­mi­za­cji jed­ne­go ERP) w firmie.

P.S.

2014-10-14 Ukazał się cie­ka­wy post na ten temat na blo­gu Trzecia Kawa:

Warto sto­so­wać kon­trakt dla usłu­gi, gdy inte­gru­je­my sys­te­my z mało mody­fi­ko­wal­nym i sła­bo zdo­ku­men­to­wa­nym API; gdy nie mamy moż­li­wo­ści spraw­dze­nia inte­gra­cji usług w trak­cie imple­men­ta­cji oraz gdy dzia­ła­my w śro­do­wi­sku o roz­pro­szo­nej odpo­wie­dzial­no­ści za inte­gra­cję systemów.Stosowanie kon­trak­tu dla usłu­gi pozwa­la unik­nąć dużych pro­ble­mów w trak­cie testów inte­gra­cyj­nych; sta­no­wi frag­ment spe­cy­fi­ka­cji sys­te­mo­wej, a w przy­pad­ku zasto­so­wa­nia mid­dle­wa­re pozwa­la na doku­men­to­wa­nie spe­cy­fi­ka­cji usłu­gi wzglę­dem okre­ślo­ne­go klien­ta. (Kontrakt świad­cze­nia usłu­gi ? Trzecia kawa).