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.

Jak połączyć prywatne z firmowym w jednym urządzeniu?

Regularnie prze­wa­la się przez bran­żo­wą pra­sę papie­ro­wą i elek­tro­nicz­ną pro­blem korzy­sta­nia z pry­wat­nych zaso­bów” w fir­mo­wych (kor­po­ra­cyj­nych) sys­te­mach IT. Problem nie jest nowy a wyglą­da mi na to, że sepa­ra­ty­stycz­ne dzia­ły IT jed­nak prze­gra­ją w tym boju.

Według róż­nych ana­liz, do 2015 roku na świe­cie ma być 15 miliar­dów urzą­dzeń pod­łą­czo­nych w sie­ci. – Działy IT powin­ny sta­wić czo­ło wyzwa­niom, któ­re się z tym wią­żą – prze­ko­nu­je nasz roz­mów­ca. – Obejmują one głów­nie obszar zapa­no­wa­nia” nad urzą­dze­nia­mi mobil­ny­mi i obszar bez­pie­czeń­stwa infor­ma­cji. (Jak połą­czyć pry­wat­ne z fir­mo­wym w jed­nym urzą­dze­niu?. wnp​.pl | Informatyka. Informatyka dla prze­my­słu.).

Przypominam sobie daw­ne dywa­ga­cje o tym jak i na jakich zasa­dach moż­na uży­wać pry­wat­ne­go samo­cho­du do celów służ­bo­wych i odwrot­nie: jak uży­wać samo­cho­du służ­bo­we­go do celów pry­wat­nych. W zasa­dzie te dys­ku­sje już uci­chły: pry­wat­ny samo­chód w pra­cy roz­li­cza­my kilo­me­trów­ką a służ­bo­wy do celów pry­wat­nych wziął na celow­nik fiskus i w zasa­dzie tu tak­że mamy stan sta­bil­ny”.

Wymagania

Od pew­ne­go cza­su obser­wu­je takie dys­ku­sje na eta­pie ana­li­zy wyma­gań na roz­wią­za­nia IT. Stale spo­ty­kam tu pew­ną złą prak­ty­kę. Generalnie w pro­jek­tach zwią­za­nych z roz­wią­zy­wa­niem pro­ble­mów i ana­li­za­mi wyma­gań dobrą prak­ty­ką jest oddzie­la­nie wyma­gań (cele) biz­ne­so­wych, od wyma­gań wobec roz­wią­za­nia (tu są wyma­ga­nia funk­cjo­nal­ne, poza funk­cjo­nal­ne i ewen­tu­al­ne dzie­dzi­no­we). Wymagania wobec roz­wią­za­nia (np. w sto­sun­ku do opro­gra­mo­wa­nia) powin­ny powstać dopie­ro pod warun­kiem, że okre­ślo­no roz­wią­za­nie, co wyda­je się być natu­ral­ną kolejnością.

Dopiero wyma­ga­nia wobec roz­wią­za­nia mogą zawie­rać ele­men­ty zwią­za­ne z, tak czę­sto pod­no­szo­nym, bez­pie­czeń­stwem. To o tyle istot­ne, że war­to wcze­śniej okre­ślić, o jakie bez­pie­czeń­stwo cho­dzi, bez­pie­czeń­stwo cze­go. Niestety czę­sto spo­ty­kam tech­no­kra­tycz­ne podej­ście pole­ga­ją­ce na uzna­niu, że bez­pie­czeń­stwo musi być, i ma być mak­sy­mal­ne” (z tego powo­du, moim zda­niem, pod­pis elek­tro­nicz­ny i jego tech­no­lo­gia były i są nadal poraż­ką: nie jest uży­wa­ny masowo).

Działy IT czę­sto zaka­zu­ją wszel­kich form nie­au­to­ry­zo­wa­ne­go” uży­cia kom­pu­te­rów czy smart- fonów pry­wat­nych do celów służ­bo­wych czy też uży­wa­nia służ­bo­we­go sprzę­tu i opro­gra­mo­wa­nia do celów pry­wat­nych. Obawiam się, że to wal­ka z wia­tra­ka­mi, zaś total­ne blo­ko­wa­nie moż­li­wo­ści insta­lo­wa­nia na służ­bo­wym note­bo­oku cze­go­kol­wiek to dro­ga doni­kąd bo blo­ku­je się ludziom moż­li­wo­ści natu­ral­ne­go wzbo­ga­ca­nia wła­snej narzę­dziow­ni” i pod­no­sze­nia pro­duk­tyw­no­ści (a nie raz pro­wa­dzi to do uda­nych prób hako­wa­nia tego sprzętu).

Specyfikowanie wyma­gań na roz­wią­za­nia i abs­tra­ho­wa­nie od tego pro­ble­mu pro­wa­dzi coraz czę­ściej do zaba­wy jaką zna­my z cza­sów popu­lar­no­ści sys­te­mów RCP (Rejestracja Czasu Pracy): pra­cow­ni­cy swój czas poświę­ca­li na oszu­ki­wa­nie sys­te­mów RCP zamiast na pra­cę. To dopro­wa­dzi­ło do odkry­cia”, że zada­nio­we roz­li­cza­nie pra­cow­ni­ków jest znacz­nie sku­tecz­niej­sze, zaś sta­no­wi­ska opła­ca­ne na zasa­dzie dyżu­ru” (dostęp­ność – obec­ność – w miej­scu pra­cy) łatwo roz­li­cza się kon­tro­lu­jąc SLA dane­go pra­cow­ni­ka (czy są na nie­go skar­gi np. sys­te­my roz­li­cza­nia usłu­gi help-desk).

Tak więc bez­pie­czeń­stwo powin­no być raczej ele­men­tem wyma­gań w posta­ci ocze­ki­wa­ny efekt” a nie jak je zapew­nić”. Nie rozu­miem dla­cze­go tak wie­lu ana­li­ty­ków i dzia­ły IT wzbra­nia­ją się przed uzna­niem, że opro­gra­mo­wa­nie powin­no być dostęp­ne na dowol­nym urzą­dze­niu mobil­nym i że nie powin­no pozwa­lać na…, i tu okre­ślo­ne ogra­ni­cze­nia. Moim zda­niem bez­pie­czeń­stwo powin­no być defi­nio­wa­ne (wyma­ga­nia) poprzez ryzy­ka, któ­rych chce­my unik­nąć w okre­ślo­nym, biz­ne­so­wo ocze­ki­wa­nym (a nawet zasta­nym) śro­do­wi­sku, a nie poprzez narzu­ca­nie kon­kret­ne­go spo­so­bu i tech­no­lo­gii, w szcze­gól­no­ści przy­mu­su korzy­sta­nia z kon­kret­ne­go sprzę­tu czy oprogramowania.

Na zakoń­cze­nie, tytu­łem małe­go a nie mówi­łem”, moje wcze­śniej­sze arty­ku­ły o cen­tra­li­za­cji z przed lat ;):

  • 1998 rok: A001_Czy_natura_dazy_do_centralnego_przetwarzania
  • 2004 rok: A011_Centralizacja_systemu_informatycznego_podejscie_procesowe

Inżynieria wymagań

W grud­niu 2011 roku napi­sa­łem na zakoń­cze­nie pew­ne­go arty­ku­łu o wymaganiach:

Większość pro­jek­tów takich jak np. wdra­ża­nie nowych metod kon­tro­lin­gu, zrów­no­wa­żo­nej kar­ty wyni­ków, nowych sys­te­mów IT itp. cier­pi głów­nie z powo­du posia­da­nia nad­mia­ru infor­ma­cji z jed­nej stro­ny i kom­plet­ne­go jej nie­zro­zu­mie­nia z dru­giej. Sławne już w bada­niach ?złe i nie­kom­plet­ne wyma­ga­nia? czy ?zmia­ny zakre­su pro­jek­tu w trak­cie jego trwa­nia? to kla­sycz­ne skut­ki złej (a czę­sto pomi­ja­nia!) ana­li­zy biz­ne­so­wej. Koszty tych pora­żek wie­lo­krot­nie prze­wyż­sza­ją koszt takich ana­liz. (Analiza biz­ne­so­wa ? sku­tecz­ne mode­lo­wa­nie a ryzy­ko pro­jek­tu).

Specyfikowanie wyma­gań, zarzą­dza­nie wyma­ga­nia­mi, inży­nie­ria wyma­gań, to jak widać bar­dzo trud­ny etap pro­jek­tu. Trudność bie­rze się stad, że dostęp­ne zale­ce­nia okre­śla­ją, że wyma­ga­nia maja być np. spój­ne i kom­plet­ne ale zupeł­nie nie opi­su­ją jak to osią­gnąć (a nawet jak to spraw­dzić).

Często moż­na się spo­tkać z poję­ciem inży­nie­ria wyma­gań”. Budzi ono mój opór z dwóch powo­dów: zna­cze­nie sło­wa inży­nie­ria w j.polskim i nie­ade­kwat­ność tego sło­wa do dzie­dzi­ny jaką jest spe­cy­fi­ko­wa­nie wyma­gań, któ­re są po pro­tu listą warunków.

Zajrzyjmy do słow­ni­ka języ­ka polskiego:

inży­nie­ria ?pro­jek­to­wa­nie i kon­stru­owa­nie obiek­tów oraz urzą­dzeń technicznych?

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Więc jak rozu­mieć zło­że­nie inży­nie­ria wyma­gań”? Ja nie wiem, chy­ba, że ktoś uwa­ża, że wyma­ga­nia się kon­stru­uje”, i że są to zagad­nie­nia tech­nicz­ne. Za to ma sens inży­nie­rii sys­te­mów”. Mamy def. poję­cia system:

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Gdyby defi­ni­cje sło­wa inży­nie­ria” okro­ić z tech­nicz­nych” albo uznać, że sys­te­my są tak­że nie tech­nicz­ne (bo są np. spo­łecz­ne) to mamy wdzięcz­na definicję:

inży­nie­ria sys­te­mów ?pro­jek­to­wa­nie i kon­stru­owa­nie ukła­dów ele­men­tów mają­cych okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Jeden z moich ulu­bio­nych auto­rów aka­de­mic­kich, Ian Sommeville (lubię go tak­że za to, że książ­ki pisze w pubach popi­ja­jąc piwo ;)) defi­niu­je inży­nie­rię wyma­gań tak:

Requirements engi­ne­ering (RE) refers to the pro­cess of for­mu­la­ting, docu­men­ting and main­ta­ining softwa­re requ­ire­ments (źr. Kotonya G. and Sommerville, I. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons)

(poję­cie inży­nie­rii wyma­gań odno­si do pro­ce­su for­mu­ło­wa­nia, doku­men­to­wa­nia i zarzą­dza­nia wymaganiami)

Tak więc uzna­jąc, że wyma­ga­nia na sys­te­my to ele­ment inży­nie­rii tych sys­te­mów, niniej­szym godzę się uży­wać poję­cia inży­nie­ria wyma­gań” w zna­cze­niu jakim opi­sał to Sommerville :).

Po co tyle glę­dze­nia o sło­wach i ich zna­cze­niach? Poza szu­ka­niem” ali­bi dla ist­nie­nia poję­cia inży­nie­ra wyma­gań” chcę poka­zać, że sło­wa mają zna­cze­nie, zanie­dby­wa­nie tego pro­wa­dzi do wie­lu nie­po­ro­zu­mień (nie­jed­no­znacz­ność) a po dru­gie zwra­cam uwa­gę, że ana­li­za poję­cio­wa to jeden z klu­czo­wych ele­men­tów ana­li­zy w ogó­le (i czę­sto zaniedbywana).

Skoro wyma­ga­nia to warun­ki, to aż pro­si się by te warun­ki spraw­dzać. Patrzmy do słownika:

spraw­dzać ?skon­tro­lo­wać, zba­dać, czy coś jest zgod­ne z praw­dą, czy coś zosta­ło zro­bio­ne prawidłowo?

Tak więc wnio­sek jest pro­sty: wyma­ga­nie (każ­de!) powin­no być spraw­dzal­ne! Bez tego nie jeste­śmy w sta­nie okre­ślić czy coś” speł­nia te wyma­ga­nia, czy­li czy zda­nie: dostar­czo­ny pro­dukt jest zgod­ny z wyma­ga­nia­mi” jest praw­dzi­we czy nie (a nie chce­my oddać roz­strzy­ga­nia tego prawnikom ;)).

Inżynieria wymagań

Skoro więc ugią­łem się i uzna­łem poję­cie inży­nie­rii wyma­gań, popa­trz­my na to sys­te­mo­wo. Jak zawsze pro­ste jest pięk­ne więc co ana­li­zu­je­my w inży­nie­rii sys­te­mo­wej i inży­nie­rii wymagań:

Granice systemu

matrioszkaPojęcie sys­tem” to tak­że super­sys­tem (sys­tem nad­rzęd­ny) i pod­sys­tem (sys­tem pod­rzęd­ny, część sys­te­mu). To trosz­kę jak zna­ne wam, być może, matriosz­ki 🙂 (figur­ki jed­na w drugiej…).

Jest to, nazew­nic­two, bar­dzo waż­ne, bo w jed­nym pro­jek­cie (doku­men­ta­cji) nale­ży zacho­wać bez­względ­ną dys­cy­pli­nę poję­cio­wą, czy­li sło­wo System powin­no się odno­sić wyłącz­nie do kon­kret­ne­go pozio­mu opi­su, resz­ta to ele­men­ty sys­te­mu nad­rzęd­ne­go lub podrzędnego.

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ń ofertowych).

Popatrzmy na powyż­szy dia­gram. Mamy tu dwa Systemy:

  1. Organizacja jest pod­sys­te­mem, jest ele­men­tem sys­te­mu, któ­rym tu jest rynek na jakim ta orga­ni­za­cja funkcjonuje.
  2. Organizacja jest ana­li­zo­wa­nym sys­te­mem, opro­gra­mo­wa­nie jest jed­nym z zaso­bów tej orga­ni­za­cji (opro­gra­mo­wa­nie jest tu podsystemem).

Wymagania może­my tu odno­sić w sto­sun­ku do Organizacji i w sto­sun­ku do Oprogramowania. To dla­te­go jasno wyod­ręb­nia­my ana­li­zę biz­ne­so­wą (pro­duk­tem są mode­le biz­ne­so­we i wyma­ga­nia biz­ne­so­we) od ana­li­zy wyma­gań na opro­gra­mo­wa­nie (mode­le i wyma­ga­nia na opro­gra­mo­wa­nie). Jak widać wyma­ga­nia na opro­gra­mo­wa­nie to wyma­ga­nia, któ­rych źró­dłem jest biz­nes, któ­ry ma kon­kret­ne cele do osią­gnię­cia. Nie powin­ny być one poboż­ny­mi życze­nia­mi użyt­kow­ni­ków, aż do momen­tu gdy spon­sor pro­jek­tu nie powie np.: moim celem jest wygo­da pra­cy moich pra­cow­ni­ków. Oczywiście, ta wygo­da jest zawsze wyma­ga­na ale nie musi ona być celem samym w sobie i nie musi mieć naj­wyż­sze­go priorytetu.

Wymagania inte­re­sa­riu­szy. Moja defi­ni­cja inte­re­sa­riu­sza (jed­na z wie­lu): oso­ba (pod­miot) zain­te­re­so­wa­na zaist­nie­niem pro­duk­tu, na któ­rą poja­wie­nie się pro­duk­tu ma wpływ. Nie raz jestem pyta­ny czy inte­re­sa­riusz ma pra­wo zgła­sza­nia wyma­gań. Jeżeli ma coś do powie­dze­nia pod­czas odbio­ru pro­duk­tu to zna­czy, że ma wyma­ga­nia. One mogą być jed­nak nie­jaw­ne czy­li taki inte­re­sa­riusz nie zgła­sza wyma­gań ale ma wpływ na odbiór pro­duk­tu, nale­ży go koniecz­nie ziden­ty­fi­ko­wać. Jeżeli zaś ktoś nie ma nic do gada­nia przy odbio­rze pro­duk­tu nie jest inte­re­sa­riu­szem (ang. sta­ke­hol­der, klu­czem jest tu «hol­der» czy­li dys­po­nent mają­cy coś do powie­dze­nia, mają­cy wpływ). Tak wiec inte­re­sa­riusz to ktoś kto, na swo­im pozio­mie ogól­no­ści, tak­że musi umieć okre­ślić, kie­dy uzna, że pro­dukt speł­nia jego wyma­ga­nia. Jak nie potra­fi, ktoś musi mu pomóc…analityk :)).

I tu rola ana­li­ty­ka. Interesariusz spi­su­je co mu przyj­dzie do gło­wy swo­im języ­kiem, ana­li­tyk upew­nia się, że zro­zu­miał, dopro­wa­dza je do posta­ci testo­wal­nej i kla­sy­fi­ku­je wyma­ga­nia” jako źró­dło: kon­kret­ny inte­re­sa­riusz” (bo każ­de wyma­ga­nie musi mieć wła­ści­cie­la). Proszę zwró­cić uwa­gę, że inte­re­sa­riu­szem jest tak­że użyt­kow­nik jeże­li tyl­ko ma coś go powie­dze­nia w projekcie :).

Popatrzmy na wymaganie:

Wymagania

Wymaganie jest jed­no (waru­nek jaki coś musi speł­nić) ale może ono mieć wie­le atry­bu­tów i tu widzę zło­żo­ność” wyma­gań (ich [[tak­so­no­mia]]). Zarówno wysta­wia­nie fak­tur VAT” jak i dostęp­ność 99,99% cza­su” to rów­no­praw­ne wyma­ga­nia bo opro­gra­mo­wa­nie np. wspo­ma­ga­ją­ce sprze­daż jest bez­war­to­ścio­we zarów­no gdy nie pozwa­la wysta­wiać fak­tur jak wte­dy, gdy czę­sto się psu­je. Owszem, jed­no jest funk­cjo­nal­ne dru­gie jest poza-funk­cjo­nal­ne ale jed­no i dru­gie to rów­no­praw­ny waru­nek przy­dat­no­ści” czy­li Wymaganie wobec oprogramowania.

Jak wspo­mnia­łem, wyma­ga­nia są (war­to tak robić) kla­sy­fi­ko­wa­ne za pomo­cą atry­bu­tów. Najczęściej spo­ty­ka­ne to: rodzaj (Kind), źró­dło wyma­ga­nia (Source), pole­cam tak­że prio­ry­tet, meto­dę wery­fi­ka­cji (np. test, audyt zgod­no­ści z opi­sem w doku­men­ta­cji), sta­tus (pla­no­wa­ne, zaakc­pe­to­wa­ne, odrzu­co­ne, …) i inne, zależ­nie od wyma­gań i typu projektu.

Ważna uwa­ga i zale­ce­nie IIBA: zarzą­dza­nie wyma­ga­nia­mi zabra­nia” ich usu­wa­nia (albo renu­me­ra­cji po usu­nię­ciu). usu­wa­nie powo­du­je to nie­spój­ność wer­sjo­no­wa­nej doku­men­ta­cji, któ­ra tak­że ma swój cykl życia. Ja od dłuż­sze­go cza­su sto­su­ję dodat­ko­wy sta­tus odrzu­co­ne”, co daje mi cią­głość doku­men­ta­cji a tak­że pozwa­la na odwie­sze­nie” wcze­śniej zde­fi­nio­wa­ne­go wyma­ga­nia, gdy ktoś jed­nak uzna, że coś co było zbęd­ne nagle zno­wu sta­je się konieczne :).

Liczba pytań i suge­stii (tak­że na kil­ku forach dys­ku­syj­na) skło­ni­ła mnie do pod­ję­cia pró­by zbu­do­wa­nia tak­so­no­mii wyma­gań. Jak już wspo­mnia­łem wyżej, zale­ce­nia takie jak FURPS to nie­ste­ty tyl­ko pła­ska lista cech” (i nie wszyst­kich). Wydaje mi się, że struk­tu­ra wyma­gań, ich tak­so­no­mia wza­jem­ne zależ­no­ści oraz rela­cje do udzia­łow­ców pro­jek­tu (inte­re­sa­riu­sze) i przy­szłych użyt­kow­ni­ków roz­wią­za­nia, wyma­ga­ją bar­dziej for­mal­ne­go podej­ścia. Celem jest uzy­ska­nie moż­li­wo­ści spraw­dza­nia czy wyma­ga­nia – jako przed­miot inży­nie­rii wyma­gań – speł­nia­ją jakieś, trze­ba je stwo­rzyć, wymagania.

Taksonomia wymaganPowyżej pró­ba usys­te­ma­ty­zo­wa­nia wyma­gań” na bazie wyżej cyto­wa­nych defi­ni­cji tego pojęcia.

Na koniec jesz­cze kolej­na waż­na rzecz. Warto wska­zy­wać, któ­re ele­men­ty logi­ki biz­ne­so­wej (Model) odpo­wia­da­ją (są powią­za­ne) z danym wyma­ga­niem bo np. szcze­gó­ło­wo opi­su­ją wyma­ga­ny spo­sób reali­za­cji dane­go wyma­ga­nia (np. sys­tem upu­stów albo kon­kret­ny przy­pa­dek uży­cia, tak­że Model). Warto tak­że, jeże­li opis wyma­ga­nia nie jest testem, zapro­jek­to­wać test (przy­pa­dek testo­wy), któ­ry potwier­dzi speł­nie­nie wyma­ga­nia np. opro­gra­mo­wa­nie ma pozwa­lać na wyli­cza­nie pier­wiast­ków dru­gie­go i trze­cie­go stop­nia”. Tu war­to podać kil­ka kon­kret­nych danych wej­ścio­wych wraz z pra­wi­dło­wy­mi wyni­ka­mi (może to doty­czyć nap. tabe­li upu­stów, sys­te­mu sko­rin­gu klien­tów itp.).

Tego typu meto­dy maja nazwę deklaratywnych:

Programowanie dekla­ra­tyw­ne ? rodzi­na para­dyg­ma­tów pro­gra­mo­wa­nia, któ­re nie są z natu­ry impe­ra­tyw­ne. W prze­ci­wień­stwie do pro­gra­mów napi­sa­nych impe­ra­tyw­nie, pro­gra­mi­sta opi­su­je warun­ki, jakie musi speł­niać koń­co­we roz­wią­za­nie (co chce­my osią­gnąć), a nie szcze­gó­ło­wą sekwen­cję kro­ków, któ­re do nie­go pro­wa­dzą (jak to zro­bić). Programowanie dekla­ra­tyw­ne czę­sto trak­tu­je pro­gra­my jako pew­ne hipo­te­zy wyra­żo­ne w logi­ce for­mal­nej, a wyko­ny­wa­nie obli­czeń jako ich dowo­dze­nie. Programowanie dekla­ra­tyw­ne jest szcze­gól­nym przed­mio­tem zain­te­re­so­wa­nia naukow­ców, gdyż dzię­ki mini­ma­li­za­cji lub eli­mi­na­cji skut­ków ubocz­nych może zna­czą­co upro­ścić two­rze­nie pro­gra­mów współ­bież­nych. Paradygmat pro­gra­mo­wa­nia dekla­ra­tyw­ne­go obej­mu­je sze­ro­ką gamę języ­ków pro­gra­mo­wa­nia i bar­dziej szcze­gó­ło­wych para­dyg­ma­tów pod­rzęd­nych. (Programowanie dekla­ra­tyw­ne ? Wikipedia, wol­na ency­klo­pe­dia).

Analiza wymagań – zrozumienie

Dzisiaj krót­ki arty­kuł o wyma­ga­niach dzie­dzi­no­wych. W jed­nym z poprzed­nich arty­ku­łów pisa­łem o wyma­ga­niach, że pro­blem tkwi w ich zro­zu­mie­niu i o tym, że przy­szły użyt­kow­nik nie powi­nien pisać jaki ma być ten pro­gram”, bo popy­cha pro­jekt w stro­nę cha­otycz­nych oczekiwań.

I tu jest sed­no: ana­li­za nie powin­na być tyl­ko pasmem wywia­dów, któ­re­go pro­duk­tem będę set­ki stron zapi­sów z ankiet i prze­pro­wa­dzo­nych roz­mów. Analiza, to duża pra­ca, któ­rej celem powin­no być zro­zu­mie­nie a nie tyl­ko opi­sa­nie. (Analiza wyma­gań na opro­gra­mo­wa­nie czy­li opi­sa­nie czy zro­zu­mie­nie).

Wymagania naj­czę­ściej dzie­li­my na funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Warto jed­nak upo­rząd­ko­wać pro­jekt i ukie­run­ko­wać ana­li­zę naj­pierw na wyma­ga­nia biz­ne­so­we a potem do już wymie­nio­nych dodać wyma­ga­nia dzie­dzi­no­we. Te ostat­nie są tak na praw­dę wydzie­le­niem z cha­osu ocze­ki­wań cze­goś co nazwę jak to jest robio­ne” ale nie w kon­tek­ście opro­gra­mo­wa­nia (pro­gra­mi­ści wie­dzą jak pro­gra­mo­wać), a w kon­tek­ście reguł biz­ne­so­wych i decy­zyj­nych (wie­dzy o tym jak się rze­czy dzieją).

Oprogramowania bez­po­śred­nio doty­czą tyl­ko wyma­ga­nia funk­cjo­nal­ne, poza-funk­cjo­nal­ne i dzie­dzi­no­we. Wymagania biz­ne­so­we to cele jakie ma przed sobą orga­ni­za­cja, dla któ­rej ma powstać (ma zostać jej dostar­czo­ne) opro­gra­mo­wa­nie. Zresztą, nie nale­ży o tym zapo­mi­nać, że może ist­nieć inne roz­wią­za­nie pro­ble­mu orga­ni­za­cji, niż oprogramowanie.

Oprogramowanie pro­jek­to­wa­ne meto­da­mi obiek­to­wy­mi wg. naj­lep­szych prak­tyk i wzor­ców ma nastę­pu­ją­ca strukturę:

Model systemu wymagania

Aktor to oczy­wi­ście jego użyt­kow­nik. Oprogramowanie, jako narzę­dzie pra­cy, świad­czy usłu­gi jego użyt­kow­ni­kom – akto­rom, jest ich narzę­dziem pra­cy. Oprogramowanie zawiera:

  1. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za jakość świad­czo­nych usług, to kla­sy reali­zu­ją­ce przy­pad­ki uży­cia tego oprogramowania,
  2. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za logi­kę biznesową,
  3. kla­sy (struk­tu­ry opro­gra­mo­wa­nia) odpo­wia­da­ją­ce za utrwa­la­nie infor­ma­cji (obiek­ty biznesowe).

Wymagania to warun­ki jakie ma speł­niać opro­gra­mo­wa­nie by było przy­dat­ne. Tak więc Analityk biz­ne­so­wy powi­nien zro­zu­mieć jak dzia­ła orga­ni­za­cja, zde­fi­nio­wać narzę­dzie jakie jej pomo­że, opi­sać wyma­ga­nia na to narzę­dzie. Jak? Powiem ina­czej, nie jest rolą pro­gra­mi­stów odkry­wa­nie” logi­ki biz­ne­so­wej, pro­gra­mi­sta odpo­wia­da za jej imple­men­ta­cję. Dlatego war­to pamię­tać o wyma­ga­niach dzie­dzi­no­wych… nie jest to nie­ste­ty miej­sce na szcze­gó­ło­wy ich opis, tu zapra­szam na szko­le­nie o wyma­ga­niach, któ­re pro­wa­dzę.

Praktyka nie­ste­ty poka­zu­je, że zapis ocze­ki­wań użyt­kow­ni­ka i prze­ka­za­nie ich pro­gra­mi­stom to dro­ga na manow­ce… Oczekiwania w rodza­ju roz­wi­ja­ne listy, mysz­ko­lo­gia”, łatwe w uży­ciu ekra­ny” i cała masa innych szcze­gó­łów nijak się ma do tego jak to opro­gra­mo­wa­nie ma dzia­łać. To tyl­ko cechy użyt­ko­we inter­fej­su użyt­kow­ni­ka, te jed­nak bez wewnętrz­nej logi­ki po pierw­sze o niczym nie mówią, a po dru­gie i tak są efek­tem goto­wych ele­men­tów z jakich budu­je się inter­fejs użyt­kow­ni­ka. Warto o ich wspo­mnieć by zama­wia­ją­cy miał ich świa­do­mość ale nie oszu­kuj­my się, opi­su­je­my tak tyl­ko to co zna­my już z innych apli­ka­cji a to w pew­nym sen­sie stan­dard (np. doty­ko­wy ekran smart­fo­na czy tabletu).

Zapisanie zaś, że sys­tem ma pozwa­lać na dobór pro­mo­cji dla klien­tów o róż­nych pozio­mach zaku­pów, po pierw­sze nic nie mówi, po dru­gie wyma­ga ana­li­zy o co cho­dzi” i są to wła­śnie wyma­ga­nia dzie­dzi­no­we­go. Wymaganiem funk­cjo­nal­nym będzie tu to: System pozwa­la na zarzą­dza­nie listą upu­stów. W języ­ku pol­skim i nie tyl­ko funk­cja to zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz. Innymi sło­wy wyma­ga­nie funk­cjo­nal­ne to to do cze­go ma słu­żyć opro­gra­mo­wa­nie a nie to jak ma to robić.

Przypomnę na zakoń­cze­nie: powyż­sze to tyl­ko pew­ne dobre prak­ty­ki 🙂 bazu­ją­ce na meto­dach obiek­to­wych (a w zasa­dzie takie głów­nie są teraz a w uży­ciu) i wzor­cach projektowych.

Recepta na porażkę

business_scenario

Wiedza to wszyst­ko to co wie­my 🙂 (tru­izm). Pytając kogoś o dro­gę może­my usły­szeć: idź pro­sto dro­gą przez las, za samot­ną brzo­zą skręć w lewo a potem kie­ruj się na wie­żę ratu­sza i doj­dziesz do mia­sta. Tak powie czło­wiek, któ­ry zna mój cel podró­ży: wie gdzie idę oraz wie któ­rę­dy iść (wie­dza). Ma to miej­sce wte­dy, gdy czło­wiek ten, prze­szedł tę dro­gę co naj­mniej raz, zaś kolej­na podróż, tu moja, ma ten sam cel i odby­wa się w tych samych warun­kach. Może się jed­nak oka­zać, że napo­tka­ny nie zna celu bo jesz­cze tam nie był, jed­nak wie­le podró­żu­je i zna lasy i doli­ny”, rozu­mie las i radzi sobie dobrze nawet w tym lesie, któ­ry widzi pierw­szy raz. Mimo, że nie był u celu, któ­ry jest naszym celem, ma doświad­cze­nie i też ma dużą wie­dzę ale inną: to jest tak zwa­ny [[survi­val]] czy­li też wie­dza (w tym doświad­cze­nie) ale nie­co inna. (kto był har­ce­rzem i brał udział w bie­gach na orientację?).

Przeżycie w lesie wyma­ga nie tyl­ko wie­dzy o tym co robić ale tak­że o tym cze­go nie robić. Ta dru­ga zresz­tą – para­dok­sal­nie – bywa cen­niej­sza, bo nie raz ratu­je życie. Wchodząc do lasu zapew­ne nie dowie­my się jakie zwie­rzę­ta spo­tka­my ale doświad­czo­ny wędrow­ca powiem nam nie doty­kaj kolo­ro­wych węży” bo wie, że te są z regu­ły bar­dzo jado­wi­te. Jak nazwie­my wte­dy zacze­pia­nie każ­de­go kolo­ro­we­go stwo­rze­nia w lesie? Jest to antyw­zo­rzec postę­po­wa­nia – ich zna­jo­mość, antyw­zor­ców, to tak­że cen­na wiedza.

Skąd się bio­rą antyw­zor­ce? Jak się nie trud­no domy­śleć, naj­czę­ściej nie z wła­sne­go doświad­cze­nia a z cudze­go. Owszem same­mu tak­że moż­na się popa­rzyć i prze­żyć, ale znacz­nie bez­piecz­niej jest prze­czy­tać kil­ka razy o popa­rze­niach, zro­zu­mieć dla­cze­go do nich wte­dy” doszło, i same­mu omi­jać oka­zje” do popa­rzeń. Jednak omi­ja­nie nie ozna­cza nic­nie­ro­bie­nie”, a nie robie­nie tego co pro­wa­dzi (z dużym praw­do­po­do­bień­stwem) do poparzeń.

Zapewne w tym momen­cie ode­zwą się piew­cy dość zna­ne­go cytatu:

?Wszyscy wie­dzą, że cze­goś nie da się zro­bić, i przy­cho­dzi taki jeden, któ­ry nie wie, że się nie da, i on wła­śnie to robi.? (Albert Einstein)

Jednak sło­wa te nie mają nic wspól­ne­go z tym co się czę­sto Einsteinowi tu przy­pi­su­je i o czym ja tu piszę. Ja piszę o antyw­zor­cach a Einstein o rezy­gna­cji z nie­wie­dzy. Antywzorzec to wzór” postę­po­wa­nia pro­wa­dzą­ce­go (z dużym praw­do­po­do­bień­stwem) do poraż­ki. Rezygnacja to zwy­kłe zanie­cha­nie, któ­re­go przy­czy­ną jest czę­sto nie­wie­dza (lub strach).

Klasyczną sytu­acją uży­cia antyw­zor­ca jest ta, w któ­rej ktoś sto­su­je w swo­im pro­jek­cie wzo­rzec” postę­po­wa­nia dają­cy 80% szans na poraż­kę. Einstein zaś pisze o kimś, kto jest prze­ko­na­ny, że coś jest nie­moż­li­we i z tego powo­du nie podej­mu­je się tego. W nauce nie­ma rze­czy nie­moż­li­wych”, są jedy­nie jesz­cze nie­zro­zu­mia­ne”. To prze­ko­na­nie w praw­dzi­wej nauce powo­du­je, że nauko­wiec nie zanie­cha, jed­nak nie nale­ży tego mylić z postę­po­wa­niem niemądrym.

Czym jest więc ten Antywzorzec, o któ­rym chcę dziś napisać? 

W pro­jek­tach z dzie­dzi­ny IT zna­na jest sta­ty­sty­ka mówią­ca, że ok. 70% pro­jek­tów to klę­ski czy­li nie­do­trzy­ma­ne ter­mi­ny, prze­kro­czo­ne budże­ty i nie­zre­ali­zo­wa­ne pla­ny, a są rapor­ty mówią­ce nawet o 80%. Tak więc jaki jest ten antyw­zo­rzec? Znamy go z badań ankie­to­wych – meto­dy pra­cy jakie sto­so­wa­no w nie­uda­nych pro­jek­tach. Oto on – Antywzorzec ana­li­zy biznesowej:

83% pro­jek­tów korzy­sta z doku­men­tów tek­sto­wych oraz arku­szy kal­ku­la­cyj­nych do prze­cho­wy­wa­nia wyma­gań, 40% pro­jek­tów korzy­sta z ema­ili do zbie­ra­nia wyma­gań i komu­ni­ka­cji z klientem. […]

Twierdzenia, że nie da się ina­czej, klien­ci nie wie­dzą cze­go chcą, doku­men­ty tek­sto­we to jedy­ne moż­li­we opi­sy wyma­gań itp. są pro­stu nie praw­dą, to uspra­wie­dli­wie­nia bra­ku kom­pe­ten­cji albo zawy­ża­nia kosz­tów pro­jek­tów (a raczej pokry­wa­nia bra­ku kom­pe­ten­cji pie­niędz­mi z kie­sze­ni klientów).

Z dru­giej stro­ny pewien zna­jo­my, współ­wła­ści­ciel pew­nej fir­my pro­gra­mi­stycz­nej, napi­sał mi niedawno:

?korzy­ści z takie­go [sfor­ma­li­zo­wa­ne] doku­men­to­wa­nia wyma­gań są ogrom­ne. Wykonawca, któ­ry potra­fi pra­co­wać na mode­lach ma 2 – 3 krot­nie niż­sze kosz­ty i 1,5 – 4 krot­nie krót­szy czas wyko­na­nia (Raport Jama Sofware ? O wyma­ga­niach).

Jak wiec brzmi recep­ta na porażkę:

Wymagania zbie­raj wyłącz­nie jako efekt burz mózgów i wywia­dów z przy­szły­mi użyt­kow­ni­ka­mi oraz ich prze­ło­żo­ny­mi, niech wszy­scy spi­szą je w posta­ci tabe­li np. w arku­szu kal­ku­la­cyj­nym i edy­to­rze tek­stu. Organizuj dłu­gie spo­tka­nia warsz­ta­to­we, po któ­rych powsta­ją kolej­ne wier­sze w tych tabe­lach i zmie­nia­ne są już wcze­śniej zapi­sa­ne. Wszystkie dodat­ko­we usta­le­nia zała­twiaj mailem ad-hoc. Tak powsta­łą tabe­lę nazwij Wymagania i daj do realizacji. 

Projekty infor­ma­tycz­ne w fir­mach to zawsze nowy cel i nowa dro­ga ale dobrze zna­ne śro­do­wi­sko pro­jek­to­we. Dlatego wzor­ce jak naj­bar­dziej mają sens, ale nie recep­ty bo te tu nie mają zasto­so­wa­nia. Antywzorce, hm…, zna­my sta­ty­sty­ki i mimo to sta­le podej­mo­wa­ne są nowe pro­jek­ty, w któ­rych klu­czo­wą meto­dy­ką pra­cy jest warsz­tat oraz ana­li­tyk-dyk­ta­fon, to czy zapi­su­je­my to jako slaj­dy pre­zen­ta­cji czy z pomo­cą nawet bar­dzo dobre­go narzę­dzia CASE nie ma żad­ne­go zna­cze­nia, jeże­li fak­tycz­nie zapi­su­je­my jedy­nie to, opis i obraz­ki, co podyk­tu­je Święty User.

Na zakoń­cze­nie jed­no zda­nie: poja­wie­nie się metod zwin­nych (rok 2001, Agile Manifesto) nie zmie­ni­ło tej czar­nej sta­ty­sty­ki (a zna­na jest od lat 80-tych) nawet o jotę, więc nic wska­zu­je na to, że są one w czym­kol­wiek lep­sze. Wiadomo zaś, że sto­so­wa­nie metod for­mal­nych jest bar­dzo sku­tecz­ne ale kosz­tow­niej­sze od opi­sa­nych wyżej maili, arku­szy i tek­stów. Jednak jeże­li śred­nie prze­kro­cze­nie kosz­tów pro­jek­tów pro­wa­dzo­nym meto­da­mi nie­sfor­ma­li­zo­wa­ny­mi docho­dzi do 200%, to zna­czy, że jed­nak meto­dy for­mal­ne są per sal­do znacz­nie tań­sze… a są sto­so­wa­ne tam, gdzie ryzy­ko jest duże” a przy­naj­mniej ryzy­ko nie jest igno­ro­wa­ne. Czemu jed­nak tak rzad­ko sto­su­je się meto­dy for­mal­ne? Bo jest róż­ni­ca pomię­dzy wie­dzieć a umieć… Jeżeli więc ktoś mówi, nie rób tego tak, bo to się raczej nie uda” (powyż­sze sta­ty­sty­ki) to war­to tego posłu­chać i zapy­tać o pozo­sta­łe 20% bar­dziej uda­nych projektów.

W kwe­stii humo­ru pro­po­nu­je lek­tu­rę Cynical Agile and Scrum Dictionary.

P.S.

2013-03-17, wpadł mi dzi­siaj w oko wpis kole­gi zaj­mu­ją­ce­go się archi­tek­tu­rą kor­po­ra­cyj­ną. Podał inną, nie tak odle­głą od mojej, recep­tę na porażkę ;)):

To naj­czę­ściej depar­ta­ment biz­ne­so­wy chce ?na szyb­ko dowieźć? roz­wią­za­nie IT (mieć tzw. quick-win’a), nie oglą­da­jąc się na ostrze­że­nia pada­ją­ce z ust archi­tek­ta kor­po­ra­cyj­ne­go ? żeby nie robić roz­wią­zań ?wią­za­nych dru­tem?, żeby uwa­żać na stan­dar­dy, żeby prze­strze­gać pryn­cy­piów archi­tek­to­nicz­nych, żeby zgła­szać wszyst­kie zmia­ny i odstęp­stwa od mode­lu doce­lo­we­go ?. I co ? i wów­czas ?biz­nes? patrzy na takie­go archi­tek­ta i mówi ?co za idio­ta?, chce spo­wol­nić pra­ce, unie­moż­li­wia osią­gnię­cie kwar­tal­nych celów itp… Nie słu­cha go, i podej­mu­je decy­zję o wdro­że­niu roz­wią­za­nia IT, nie­zgod­ne­go z przy­ję­tą w orga­ni­za­cji archi­tek­tu­rą, obo­wią­zu­ją­cy­mi stan­dar­da­mi, pryn­cy­pia­mi. Bardzo czę­sto te pra­ce są jesz­cze przy­spie­sza­ne na sku­tek pod­szep­tów dostaw­cy zewnętrz­ne­go, któ­ry mówi tyl­ko ?miłe słów­ka? biz­ne­so­wi ? że archi­tek­ci to hamul­co­wi, że tyl­ko by się dro­czy­li z biz­ne­sem bo chcą udo­wod­nić swo­ją rolę w orga­ni­za­cji, bo my (tj. dostaw­cy) wdro­ży­my takie roz­wią­za­nie 3x szyb­ciej niż mówi to zespół archi­tek­to­nicz­ny i wewnętrz­ne IT. (Przypowieść o kare­cie a pra­ce archi­tek­ta kor­po­ra­cyj­ne­go | Architektura Korporacyjna).

Dom bez planów

Proces zbierania i analizy wymagań u developera

Dziś nie­co kon­tro­wer­syj­ny arty­kuł, kry­ty­ka naj­czę­ściej sto­so­wa­nych metod ana­li­zy wyma­gań. Pojawią się tu cyta­ty ze stron dużych firm dostar­cza­ją­cych opro­gra­mo­wa­nie. Są to kry­ty­ko­wa­ne prze­ze mnie opi­sy metod pra­cy. Jednak z mojej stro­ny będzie tu: nie moje widzi­mi­się” jako wła­ści­wa meto­da”, a meto­dy powszech­nie uzna­ne za sku­tecz­ne i opi­sa­ne w sie­ci i w lite­ra­tu­rze. Osobiście zresz­tą uwa­żam, że wie­le tak zwa­nych autor­skich meto­dyk” to albo udziw­nio­ne i nad­mier­nie kom­pli­ko­wa­ne stan­dar­dy (czy­taj pod­nie­sio­ne kosz­ty ana­li­zy), albo ubra­ne w pro­ce­du­ry” meto­dy tu kry­ty­ko­wa­ne (czy­li tak­że pod­nie­sio­ne kosz­ty ale już dal­szych etapów).

Bardzo czę­sto z ust dostaw­ców opro­gra­mo­wa­nia, moż­na usły­szeć o takim podzia­le wyma­gań, któ­ry co cie­ka­we, trud­no zna­leźć w opi­sach stan­dar­dów metod ana­li­tycz­nych (np. OMG​.org):

Wymaganie jest potrze­bą klien­ta, któ­ra wpły­wa na powsta­nie nowe­go roz­wią­za­nia lub zmie­nia roz­wią­za­nie już ist­nie­ją­ce. Ze wzglę­du na poziom szcze­gó­ło­wo­ści wyma­ga­nia mogą być biz­ne­so­we lub sys­te­mo­we.

Wymaganie biz­ne­so­we reali­zo­wa­ne jest poprzez jed­no lub zbiór wyma­gań sys­te­mo­wych. Przykładem może być Import pli­ków z umo­wa­mi. Wymaganie to moż­na zre­ali­zo­wać poprzez dwa wyma­ga­nia sys­te­mo­we: import pli­ków i obsłu­ga zaim­por­to­wa­nych plików.

Wymagania sys­te­mo­we doty­czą bez­po­śred­nich funk­cjo­nal­no­ści sys­te­mu. Złożone wyma­ga­nia sys­te­mo­we moż­na przed­sta­wić za pomo­cą bar­dziej szcze­gó­ło­wych, np. Import pli­ków obej­mu­je wyko­na­nie spraw­dzeń i wali­da­cji na zaim­por­to­wa­nych danych oraz pro­ces zapi­su umów z pli­ku impor­tu w sys­te­mie.

Pojawia się poję­cie Import pli­ku z umo­wa­mi”. Jaki to ma zwią­zek z biz­ne­sem? Domyślać się moż­na jedy­nie, że te umo­wy gdzieś są i w jakimś celu powin­ny być gdzieś dostęp­ne, ale nie jestem prze­ko­na­ny by użyt­kow­nik od razu wyar­ty­ku­ło­wał, że chce mieć ich import”. To poję­cie techniczne.

Osobiście pole­mi­zu­ję z takim podej­ściem nie tyl­ko dla­te­go, że trud­no o wska­za­nie pod­staw takie­go a nie inne­go podzia­łu wyma­gań. Także dla­te­go, że jest to pro­ces z grun­tu ryzy­kow­ny. Po trze­cie, powyż­sze defi­ni­cje nie speł­nia­ją pod­sta­wo­we­go kry­te­rium słow­ni­ka pojęć: poję­cia danej prze­strze­ni nazw nie mogą być defi­nio­wa­ne z pomo­cą innych pojęć tej samej prze­strze­ni. Takie błę­dy pro­wa­dzą do tak zwa­ne­go masła maśla­ne­go, co wyszło dość szyb­ko, bo tekst w dal­szej czę­ści tre­ści cyto­wa­nej stro­ny zaprze­cza czę­ści wcze­śniej­szej defi­ni­cji wymagań:

Zgodnie z teo­rią spe­cy­fi­ka­cja powin­na zawie­rać przede wszyst­kim wyma­ga­nia zapre­zen­to­wa­ne z punk­tu widze­nia klien­ta i w ter­mi­nach dla nie­go zro­zu­mia­łych. Powinna stwier­dzać, co ma zostać zre­ali­zo­wa­ne, a nie jak nale­ży to zro­bić. Specyfikacja wyma­gań nie może być więc pró­bą pro­jek­to­wa­nia systemu.

i z tym nale­ży się zgo­dzić w 100%, wiec co robi tu import pli­ku w raz całym opi­sem ich obsłu­gi, wali­da­cji itp. (w peł­nym tek­ście cyto­wa­nym jako wyma­ga­nie opi­sa­no pro­ces impor­tu pliku).

Po pierw­sze kim tu jest Klient? Gdzie jest użyt­kow­nik? Dlaczego wyma­ga­nie okre­śla spo­sób reali­za­cji wyma­ga­nia (Import pli­ków obej­mu­je…)? Co to są bez­po­śred­nie funk­cjo­nal­no­ści sys­te­mu”? Skoro są bez­po­śred­nie to czym są nie­bez­po­śred­nie funk­cjo­nal­no­ści” i gdzie je opisano?

Ogólnie poję­cie wyma­ga­nia sys­te­mo­we”, będą­ce pró­bą opi­su jak to ma być zro­bio­ne” nie mają żad­nej racji bytu jako Wymaganie Klienta. W ogó­le lite­ra­tu­ra (nie licząc masy mier­nej jako­ści porad­ni­ków) nie zawie­ra poję­cia wyma­ga­nie sys­te­mo­we” w zna­cze­niu innym niż wyma­ga­nia na plat­for­mę sprzę­to­wo-sys­te­mo­wą. Jednak te wyma­ga­nia powi­nien okre­ślić wyko­naw­ca na eta­pie pro­jek­tu imple­men­ta­cji a nie biznes.

W moich oczach doku­men­ta­cja wyma­gań powsta­ła na bazie powyż­szych defi­ni­cji, jest po pro­stu nie­we­ry­fi­ko­wal­na (pole­cam wpis o szko­dli­wo­ści dwu­znacz­no­ści tre­ści doku­men­ta­cji). Po dru­gie war­to wie­dzieć, że zama­wia­ją­cy nie jest w sta­nie (i nie powi­nien) pre­cy­zo­wać wyma­gań innych niż biz­ne­so­we zaś wyko­naw­ca (pro­gra­mi­sta, deve­lo­per) ocze­ku­je pro­jek­tu a nie wyma­gań. Wymagania ma – okre­śla – zama­wia­ją­cy, swo­im języ­kiem (więc raczej nie import umów”), ktoś powi­nien umieć je zwe­ry­fi­ko­wać (audyt) i zamie­nić na pro­jekt tego co ma wyko­nać (dostar­czyć) dostaw­ca opro­gra­mo­wa­nia. Dokładnie tak jest w innych dzie­dzi­nach inży­nie­rii, np. budowlanej.

Cytowany opis to mniej wię­cej taki pro­sty model ról w projekcie:

Mamy użyt­kow­ni­ka, któ­ry ma wyma­ga­nia co do opro­gra­mo­wa­nia, ana­li­tyk wyma­gań je zbie­ra (sesje warsz­ta­to­we, ankie­ty, spo­tka­nia, wywia­dy, inne) i wery­fi­ku­je. Powstaje spe­cy­fi­ka­cja. Tak powsta­łe spe­cy­fi­ka­cje wyma­gań nie pod­da­ją się żad­nej wery­fi­ka­cji na kom­plet­ność i spój­ność, są dekla­ra­cją użyt­kow­ni­ków bez gwa­ran­cji, że nie odkry­je­my nowych wyma­gań lub nie uzna­my wie­lu z nich za nadmiarowe.

Jak wyglą­da zale­ca­ny proces? 

Bazuje na pro­stej” kolej­no­ści dzia­łań opi­sa­nej na stro­nach OMG​.org pod nazwą pro­ces MDA”, nie raz w moim blo­gu przy­wo­ły­wa­ny. Proces ten ma na trzy klu­czo­we kroki:

  1. opra­co­wa­nie mode­lu fir­my: model biz­ne­so­wy (pro­ce­sy biz­ne­so­we, struk­tu­ra org., regu­ły biz­ne­so­we), jest to tak zwa­ny model CIM (Computing Independent Model), celem jego powsta­nia jest zbu­do­wa­nie narzę­dzia opi­su­ją­ce­go fir­mę Klienta, któ­re posłu­ży dopie­ro do zde­fi­nio­wa­nia i wery­fi­ka­cji wymagań.
  2. opra­co­wa­nie mode­lu PIM (Platform Independent Model), jest to opis usług sys­te­mu i ich logi­ki bez żad­nych infor­ma­cji o imple­men­ta­cji, to pro­jekt oprogramowania.
  3. opra­co­wa­nie mode­li PSM (Platform Specyfic Model), jest to opis tego jak model PIM ma być imple­men­to­wa­ny (zre­ali­zo­wa­ny) i to dopie­ro robi developer.

Całość bazu­je na kla­sycz­nej ana­li­zie sys­te­mo­wej (zwa­ną tez meto­da nauko­wą). Bazując na tym opi­sie powin­no więc być tak:

Wygląda na dość skom­pli­ko­wa­ny pro­ces ale to pozo­ry. Sponsor pro­jek­tu, klu­czo­wa postać w ana­li­zie wyma­gań, okre­śla cele biz­ne­so­we. One wyzna­cza­ją wszel­kie prio­ry­te­ty w dal­szej ana­li­zie np. prio­ry­te­ty wyma­gań. Sponsor sta­wia cele biz­ne­so­we np. pod­nie­sie­nie jako­ści obsłu­gi rekla­ma­cji poprzez eli­mi­na­cję przy­pad­ków zagu­bień doku­men­tów. Powstaje model CIM, z jego pomo­cą wyszu­ku­je­my miej­sca, w pro­ce­sach biz­ne­so­wych, w któ­rych te doku­men­ty giną lub jest ryzy­ko zagi­nię­cia. I tak prze­cho­dzi­my wszyst­kie wyma­ga­nia biz­ne­so­we. Tu wyma­ga­niem biz­ne­so­wym jest cel spon­so­ra, lista jego potrzeb i w kon­se­kwen­cji dopie­ro użyt­kow­ni­ków. Jednak to nie użyt­kow­nik dekla­ru­je, że coś chce”, takie ocze­ki­wa­nie musi wyni­kać z celu spon­so­ra. Wszystkie zało­że­nia, a są nimi np. ocze­ki­wa­ne funk­cjo­nal­no­ści opro­gra­mo­wa­nia i teza, że zaspo­ka­ja­ją one wyma­ga­nia spon­so­ra pro­jek­tu, są wery­fi­ko­wa­ne z pomo­cą mode­li. Modele sa tu narzę­dziem na eta­pie ana­li­zy CIM i pro­jek­tem na eta­pie PIM.

Lista wyma­gań jako ankie­ta życzeń przy­szłych użyt­kow­ni­ków to naj­częst­sze źró­dło pro­ble­mów w projektach. 

Dalej cele biz­ne­so­we wyzna­cza­ją na mode­lu CIM jakie usłu­gi przy­szły sys­tem ma ofe­ro­wać jego użyt­kow­ni­kom, by cele biz­ne­so­we speł­nić. Np. aby doku­men­ty nie ginę­ły, należ je ska­no­wać i archi­wi­zo­wać w spo­sób bez­piecz­ny i łatwy do wyszu­ka­nia zaraz po otrzy­ma­niu. To zna­czy, że System powi­nien udo­stęp­nić usłu­gi: ska­no­wa­nie i indek­so­wa­nie, wyszu­ki­wa­nie i prze­glą­da­nie. Logika tych usług to spo­sób wza­jem­ne­go koja­rze­nia tych doku­men­tów i póź­niej­sze­go wyszu­ki­wa­nia. Dokument, któ­ry to opi­su­je to model PIM. I to wszyst­ko robi Analityk Biznesowy.

Koszty takiej analizy

Tu war­to powie­dzieć, że nie zawsze ana­li­za w posta­ci kolek­cjo­no­wa­nia np. ankiet czy wyni­ków [[sesji JAD]] jest tań­sza od pro­jek­tu reali­zo­wa­ne­go opi­sa­ną metodą.

Jeżeli ana­li­zę wyma­gań robi jed­na oso­ba, i jej kom­pe­ten­cje to tyl­ko duże doświad­cze­nie w takich wywia­dach i two­rze­nie doku­men­tów (tek­sty, tabe­le itp.), to jej koszt może być rela­tyw­nie niski, jed­nak nie­ste­ty tak opra­co­wa­na lista wyma­gań to naj­czę­ściej listy cech zawie­ra­ją­ce tak­że owe pró­by imple­men­ta­cji” (np. import pli­ków umów”), bez żad­nej gwa­ran­cji, że dla odmia­ny cze­goś oczy­wi­ste­go” a waż­ne­go nie pomi­nię­to. Brak celu biz­ne­so­we­go spon­so­ra nie daje zaś żad­ne­go narzę­dzia do odsie­wu życzeń nad­mia­ro­wych”, zwa­nych potocz­nie w pro­jek­tach poboż­ny­mi życze­nia­mi użytkowników”.

Jeżeli ana­li­za robio­na jest siłą kil­ku kon­sul­tan­tów orga­ni­zu­ją­cych sesje warsz­ta­to­we z gru­pa­mi pra­cow­ni­ków, doku­men­ta­cja ma kil­ku recen­zen­tów i trwa to np. kwar­tał, to jest to pro­ces nie mniej ryzy­kow­ny, bo pro­duk­tem tak­że jest spe­cy­fi­ka­cja życze­nio­wa, za to bar­dzo kosz­tow­na, znacz­nie kosz­tow­niej­sza niż pra­ca jego doświad­czo­ne­go ana­li­ty­ka Biznesowego.

Tego typu życze­nio­we doku­men­ty, gene­ru­ją bar­dzo duże kosz­ty na eta­pie wdra­ża­nia i zarzą­dza­nia zmia­ną (odkry­wa­nie wyma­gań i ich zmiany).

Analiza Biznesowa i spe­cy­fi­ka­cja wyma­gań opra­co­wa­na meto­dą opi­sy­wa­ną tu i na stro­nach OMG, jest od tej ostat­niej (gru­pa kon­sul­tan­tów i sesje warsz­ta­to­we) znacz­nie tań­sza. W cza­sie trwa podob­nie, jed­nak robi to z regu­ły jed­na oso­ba (tak! ale przy zało­że­niu ma sto­su­je zaawan­so­wa­ne narzę­dzia CASE nie tyl­ko do two­rze­nia dia­gra­mów ale tak­że do ich wery­fi­ka­cji śla­do­wa­nia zarzą­dza­nia spój­no­ścią mode­li itp.), a efek­tem jest pro­jekt logicz­ny a nie dopie­ro lista wyma­ga­nych cech. Korzyść jest więc podwój­na. Jeżeli zro­bi to Analityk wyna­ję­ty przez Klienta a nie Dostawcy, to wszel­kie pra­wa (know-how) do pro­jek­tu pozo­sta­ją po stro­nie nabywcy.

Można powie­dzieć, że to trud­ne i kosz­tow­ne. Trudne owszem, wyma­ga doświad­cze­nia i wie­dzy zarów­no z zakre­su zarzą­dza­nia jak i inży­nie­rii opro­gra­mo­wa­nia. Per sal­do, wli­cza­jąc w to kosz­ty mody­fi­ka­cji na eta­pie wdra­ża­nia i odkry­wa­nia wyma­gań (wady spe­cy­fi­ka­cji nie pod­da­ją­cej się wery­fi­ka­cji) jest to pro­ces zawsze tań­szy (bada­nia kie­row­ni­ków pro­jek­tów wska­zu­ją, że zła jakość wyma­gań gene­ru­je dodat­ko­we kosz­ty rzę­du 60% war­to­ści pro­jek­tu, koszt takiej ana­li­zy nie prze­kra­cza zaś 20%). Do tego poja­wia­ją się poten­cjal­ne kosz­ty nie­ujaw­nio­ne klien­to­wi: pra­wa autor­skie do pro­jek­tu i apli­ka­cji. Jeżeli fir­ma będą­ca wyko­naw­ca opro­gra­mo­wa­nia robi ana­li­zę swo­je­go klien­ta i potem mu sprze­da­je pra­wa do jej wyni­ków wraz z dostar­cza­nym opro­gra­mo­wa­niem, to jest to kla­sycz­ny przy­pa­dek aneg­do­ty o kon­sul­tan­tach, któ­rzy zapy­ta­ni o to któ­ra jest godzi­na, pro­szą Cie o Twój zega­rek, odpo­wia­da­ją na pyta­nie któ­ra godzi­na i wysta­wia­ją fak­tu­rę za usłu­gę i tak­że za zwra­ca­ny Ci Twój zegarek.

Tak więc naj­pro­ściej: mamy spon­so­ra pro­jek­tu i ewen­tu­al­nych innych zain­te­re­so­wa­nych. Oni mają wyma­ga­nia biz­ne­so­we – chcą coś w swo­ich orga­ni­za­cjach osią­gnąć lub zmie­nić. Kolejny etap to ana­li­za, któ­rej celem jest oce­na czy to moż­li­we i jak. Jako narzę­dzia pra­cy” powsta­ją model tej orga­ni­za­cji: mapy pro­ce­sów, struk­tu­ra orga­ni­za­cyj­na, sys­tem reguł i pojęć biz­ne­so­wych. Produktem tej pra­cy są reko­men­da­cje gdzie i jak moż­na osią­gnąć efek­ty wyma­gań biz­ne­so­wych. Jeżeli zapad­nie decy­zja o tym, że wyma­ga­nia biz­ne­so­we pomo­że osią­gnąć nowe opro­gra­mo­wa­nie wspie­ra­ją­ce orga­ni­za­cję, na bazie posia­da­nych mode­li opra­co­wu­je się listę wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych. Są to usłu­gi sys­te­mu jakich od nie­go ocze­ku­je­my oraz ogra­ni­cze­nia jakościowe.

Ale to za mało, taki opis jest dopie­ro wsa­dem” do pro­jek­to­wa­nia. Nie wystar­czy powie­dzieć jakiej usłu­gi ocze­ku­je­my, koniecz­ne jest opi­sa­nie tego, jaką logi­kę ma każ­da usłu­ga reali­zo­wać i jaki­mi dany­mi zarzą­dzać. Należy okre­ślić jaką wie­dzą nadal będzie dys­po­no­wał użyt­kow­nik (aktor sys­te­mu) a jaką wie­dzę” ma posia­dać opro­gra­mo­wa­nie świad­czą­ce wyma­ga­ną usłu­gę (np. kto ma umieć poli­czyć poda­tek VAT na fak­tu­rze: użyt­kow­nik czy opro­gra­mo­wa­nie do fak­tu­ro­wa­nia). Dopiero taki opis sta­no­wi jasne zada­nie” dla dostaw­cy opro­gra­mo­wa­nia, któ­ry powi­nien zostać wybra­ny dopie­ro po tym, jak będzie­my dys­po­no­wa­li opi­sem tej logi­ki i jej ogra­ni­cze­nia­mi. Dlaczego? Dostawcy się zawsze w czymś spe­cja­li­zu­ją, ta spe­cja­li­za­cja jest czyn­ni­kiem wpły­wa­ją­cym na to, któ­ry zre­ali­zu­je nasz pro­jekt naj­le­piej. Jeżeli to przy­szły wyko­naw­ca wyko­na ana­li­zę i pro­jekt, jest pra­wie pew­ne, że będzie on opty­mal­ny z per­spek­ty­wy spe­cja­li­za­cji wyko­naw­cy a nie z per­spek­ty­wy wyma­gań Zamawiającego.