Wymagania pozafunkcjonane czyli jaka architektura

Poza wyma­ga­nia­mi funk­cjo­nal­ny­mi, poda­je­my tak zwa­ne wyma­ga­nia poza-funk­cjo­nal­ne. Mają one, mię­dzy inny­mi, waż­na rolę do speł­nie­nia. Jaką?

Najpierw cytat:

Technologia klient/serwer jest zależ­na od komu­ni­ka­cji pomię­dzy poszcze­gól­ny­mi kom­pu­te­ra­mi. Sieci LAN i WAN sta­ją się znacz­nym wydat­kiem oraz wyma­ga­ją dużych nakła­dów pra­cy w związ­ku z zarzą­dza­niem nimi. Co wię­cej, zmia­na wer­sji opro­gra­mo­wa­nia na wie­lu kom­pu­te­rach, co szcze­gól­nie widocz­ne jest w przy­pad­ku prze­twa­rza­nia roz­pro­szo­ne­go, sta­je się istot­nym pro­ble­mem. Wielokrotnie dzia­ły IT zasta­na­wia­ją się nad przej­ściem na struk­tu­rę Internet/Intranet w celu roz­wią­za­nia tego pro­ble­mu. (Wstęp do ERP – tech­no­lo­gia u pod­wa­lin przedsiębiorstwa).

Pomijając pro­sto­tę” tego tłu­ma­cze­nia, chcę zwró­cić uwa­gę na waż­ną rzecz: bar­dzo duże znacz­nie ma archi­tek­tu­ra sys­te­mu, nie­ste­ty wie­lu pro­du­cen­tów ukry­wa zasto­so­wa­ną tech­no­lo­gię i archi­tek­tu­rę. Jedną z przy­czyn jest to, że są to nie raz tech­no­lo­gie rodem z lat 90-tych a bywa, że nawet wcze­śniej­sze. Jedną z takich sta­ro­ci” jest archi­tek­tu­ra client-server (tak zwa­ny gru­by klient). Innym typem dino­zau­ra” tech­no­lo­gicz­ne­go jest two­rze­nie opro­gra­mo­wa­nia, w któ­rym logi­ka biz­ne­so­wa jest w jakiejś czę­ści w pro­ce­du­rach wbu­do­wa­nych bazy danych (w rozu­mie­niu kon­kret­ne­go tak zwa­ne­go moto­ra SQL bazy).

Jaki mamy wybór?

Zanim powie­my sobie o wybo­rze, kil­ka słów na temat kla­sycz­nej trój­war­stwo­wej archi­tek­tu­ry jako fun­da­men­cie dal­szych roz­wa­żań. Struktura taka wyglą­da następująco:

Architektura trójwarstwowa

Mamy tu trzy war­stwy: Warstwa pre­zen­ta­cji, czy­li kom­po­nent odpo­wie­dzial­ny za wyświe­tla­nie infor­ma­cji na ekra­nie użyt­kow­ni­ko­wi i ich przyj­mo­wa­nie. Warstwa logi­ki apli­ka­cji podzie­lo­na na Logikę dzie­dzi­no­wą (część spe­cy­ficz­na dla dzie­dzi­ny pro­ble­mu, tu są np. fak­tu­ry, spo­sób nali­cza­nia podat­ków, raba­tów itp. ta część reali­zu­je wyma­ga­nia funk­cjo­nal­ne) oraz Logikę poza-dzie­dzi­no­wą (wydaj­ność, nie­za­wod­ność, bez­pie­czeń­stwo, inte­gra­cja z inny­mi apli­ka­cja­mi itp.). Najniżej jest war­stwa Utrwalania, coraz czę­ściej w para­dyg­ma­cie obiek­to­wym pomi­ja­na na tym pozio­mie abs­trak­cji (utoż­sa­mia­na z reali­za­cją wyma­gań poza-funk­cjo­nal­nych zwią­za­nych z zacho­wy­wa­niem informacji).

Praca w sie­ci wie­lu użyt­kow­ni­ków to wie­lo­do­stęp (wie­le sta­cji robo­czych korzy­sta z jed­ne­go serwera):

Wielodostęp

Gruby klient

Gruby klient to archi­tek­tu­ra w któ­rej każ­dy użyt­kow­nik ma na swo­im lokal­nym kom­pu­te­rze nie tyl­ko war­stwę pre­zen­ta­cji ale tak­że całą logi­kę apli­ka­cji. Każde takie sta­no­wi­sko komu­ni­ku­je się z ser­we­rem danych:

Architektura Gruby klient

Do powyż­szej archi­tek­tu­ry odno­szą się głów­ne uwa­gi o wadach z cyta­tu na począt­ku. Cechy archi­tek­tu­ry po lewej stro­nie: kosz­tow­ne sta­cje robo­cze (muszą, każ­da, udźwi­gnąć całe opro­gra­mo­wa­nie), kosz­tow­na admi­ni­stra­cja (nie­zgod­ność wer­sji na sta­cjach robo­czych może pro­wa­dzić do kra­chu sys­te­mu), kosz­tow­ne mody­fi­ka­cje (tak­że z uwa­gi na wyma­ga­ną zgod­ność opro­gra­mo­wa­nia na sta­cjach robo­czych), bar­dzo duże wyma­ga­nia na pasmo i nie­za­wod­ność sie­ci (duże trans­fe­ry danych pomię­dzy sta­cja­mi robo­czy­mi i ser­we­rem, zerwa­nie połą­cze­nia powo­du­je blo­ka­dy dostę­pu do danych) powo­du­ją, że pra­ca w sie­ci roz­le­głej tery­to­rial­nie może być wręcz nie­moż­li­wa (wte­dy wyma­ga powie­la­nia insta­la­cji w każ­dej loka­li­za­cji i syn­chro­ni­za­cji danych, kolej­ne nie­ma­łe kosz­ty). Pewną odmia­ną jest wariant po pra­wej stro­nie, gdzie część logi­ki apli­ka­cji jest umiesz­czo­na na ser­we­rze danych (kon­kret­nie bazy danych), powo­du­je to nie­co zmniej­szo­ny ruch w sie­ci ale dodat­ko­wo kom­pli­ku­je wszel­kie roz­sze­rze­nia funk­cjo­nal­no­ści i upgra­de oraz prak­tycz­nie unie­moż­li­wia zmia­nę (wybór) pro­du­cen­ta bazy danych. Duże kosz­ty tej archi­tek­tu­ry dodat­ko­wo potę­gu­je wymóg wyku­pie­nia licen­cji na bazę danych dla każ­de­go użytkownika.

W więk­szo­ści przy­pad­ków tej archi­tek­tu­ry, logi­ka biz­ne­so­wa (dzie­dzi­no­wa) nie jest sepa­ro­wa­na od resz­ty, w efek­cie dodat­ko­wo wszel­kie pra­ce dosto­so­waw­cze są bar­dzo kosz­tow­ne (inge­ren­cja w całą aplikację).

Architektura internetowa – cienki klient

Taką nazwę od pew­ne­go cza­su nada­je się archi­tek­tu­rze opar­tej na dostę­pie do apli­ka­cji z pomo­cą prze­glą­dar­ki WWW:

Architektura Cienki klient

Powyższa archi­tek­tu­ra prak­tycz­nie nie ma żad­nej wady poprzed­nie­go roz­wią­za­nia. Dodatkowo baza danych licen­cjo­no­wa­na jest z regu­ły na apli­ka­cję a nie na każ­de­go użyt­kow­ni­ka (czy­li jest taniej). Stosując tak zwa­ne meto­dy i archi­tek­to­nicz­ne wzor­ce obiek­to­we (naj­po­pu­lar­niej­szy to MVC: Model, View, Controller) sepa­ru­je się kom­po­nent logi­ki biz­ne­so­wej od logi­ki ste­ro­wa­nia apli­ka­cją. W efek­cie dosto­so­wa­nie apli­ka­cji nie pole­ga na kosz­tow­nym mody­fi­ko­wa­niu logi­ki apli­ka­cji, doda­je się i inte­gru­je nie­za­leż­ny kom­po­nent Logiki biz­ne­so­wej, co dodat­ko­wo pozwa­la zacho­wać sepa­ra­cję praw autor­skich do kodu logi­ki biz­ne­so­wej (know-how fir­my). Korzyścią takiej archi­tek­tu­ry jest tak­że moż­li­wość łatwe­go doda­wa­nia moż­li­wo­ści dostę­pu z innych niż kom­pu­ter PC, urzą­dzeń (smart­fo­ny, table­ty, itp.) gdyż wyma­ga to wyłącz­nie nowej war­stwy pre­zen­ta­cji, logia pozo­sta­je spój­na na serwerze.

Kolejna korzyść to łatwa inte­gra­cja z inny­mi apli­ka­cja­mi. Oprogramowanie w tej archi­tek­tu­rze ukry­wa” dane, dostęp do nich jest wyłącz­nie przez Logikę apli­ka­cji za pośred­nic­twem tak zwa­nych API (inter­fejs pro­gra­mi­stycz­ny) meto­da­mi zna­ny­mi w sie­ci WWW, uni­ka­my kosz­tow­nych i ryzy­kow­nych łączy bez­po­śred­nich do baz danych (niska pra­co­chłon­ność inte­gra­cji, bar­dzo wyso­kie kosz­ty utrzy­ma­nia i rozwoju).

W efek­cie reko­men­do­wa­na archi­tek­tu­ra mogła by wyglą­dać tak:

Rekomendowana architektura aplikacji

Zalety: niskie kosz­ty utrzy­ma­nia sys­te­mu i infra­struk­tu­ry, sepa­ra­cja logi­ki biz­ne­so­wej (dzie­dzi­no­wej) dedy­ko­wa­nej od kupio­nej”, łatwość i niski koszt upgra­de, pra­ca z pomo­cą prze­glą­dar­ki WWW, łatwa inte­gra­cja z inny­mi apli­ka­cja­mi, łatwość pra­cy w sie­ci lokal­nej i roz­le­głej (w tym łatwy zdal­ny dostęp z dowol­ne­go cudze­go kom­pu­te­ra). To tyl­ko głów­ne korzyści.

Wymagania pozafunkcjonalne

Jak wspo­mnia­łem, wie­lu dostaw­ców opro­gra­mo­wa­nia jak Rejtan, bro­ni się przed ujaw­nia­niem archi­tek­tu­ry, swo­ich pro­duk­tów. Głównym powo­dem jest zapo­bie­ga­nie przed­wcze­sne­go wyja­wie­nia opi­sa­nych wyżej wad sys­te­mów z gru­bym klien­tem (znacz­nie rza­dziej spek­ta­ku­lar­ny pomysł, w koń­cu mamy jed­nak jakieś stan­dar­dy). Przypadki, w któ­rych zakup sys­te­mu był rela­tyw­nie niski ale koszt utrzy­ma­nia, roz­wo­ju i dosto­so­wa­nia nie raz wręcz ogrom­ny, to z regu­ły wła­śnie zakup sys­te­mu w tej kosz­tow­nej architekturze.

Jak sta­rać się tego uni­kać? Na eta­pie defi­nio­wa­nia wyma­gań poza-funk­cjo­nal­nych, żądać takich cech jak opi­sa­ne powy­żej czy­li wła­snie: dostęp do cało­ści przez prze­glą­dar­kę WWW, niskie wyma­ga­nia na łącza przy zdal­nej pra­cy i pra­cy w sie­ci roz­pro­szo­nej tery­to­rial­nie, oddzie­le­nie kom­po­nen­tu z wła­sną dedy­ko­wa­ną logi­ką biznesową.

[2015]

Polecam poga­dan­ke M.Fowlera na temat roli architektury:

User Stories, czym jest?

O opi­so­wych meto­dach zbie­ra­nia wyma­gań napi­sa­no wie­le, eks­pe­ry­men­tu­ję cza­sa­mi z tek­sta­mi” i nabie­ram pew­ne­go prze­ko­na­nia: jako opis wyma­gań, czy­li jak chce to robić” (np. przy­pad­ków uży­cia) raczej nie, jako opis celu dzia­ła­nia, czy­li co chce osiągnąć/po co mi to” jak naj­bar­dziej. Tak więc opis z ręki zama­wia­ją­ce­go jako wsad do ana­li­zy” jak naj­bar­dziej, ale user sto­ry jako wyma­ga­nia”, raczej na pew­no nie (czy­taj User Story – kło­po­ty)…

User Story jaki jak” z regu­ły nie­ste­ty stwa­rza pro­ble­my i słusz­nie zauwa­żo­no, że:

User Story w posta­ci: Obsługa błę­dów i ich logo­wa­nie powin­no się odby­wać poprzez wspól­ny mecha­nizm” jest kiep­skim pomy­słem. Co praw­da widzi­my dość jasno, że to wyma­ga­nie jest war­to­ścio­we, ale czy użytkownik/klient będzie potra­fił oce­nić jego war­tość? Dodatkowo taki zapis zawie­ra w sobie suge­stię na temat imple­men­ta­cji spo­so­bu obsłu­gi błę­dów – czy z punk­tu widze­nia klien­ta ma to zna­cze­nie? Pamiętajmy też, że jako ana­li­ty­cy (lub jako pro­duct owner w Scrumie) nie chce­my suge­ro­wać roz­wią­za­nia pro­gra­mi­stom, któ­rzy czę­sto lepiej od nas zna­ją się na tech­no­lo­gii, któ­rej będą uży­wać. My powin­ni­śmy napi­sać, co chce osią­gnąć użyt­kow­nik i pozwo­lić pro­gra­mi­stom wybrać naj­lep­szy spo­sób imple­men­ta­cji roz­wią­za­nia. (Wartościowe User Stories ? O wymaganiach).

Moim zda­niem tak zwa­ne user sto­ry powin­no być napi­sa­ne: po pierw­sze języ­kiem zama­wia­ją­ce­go, po dru­gie wyłącz­nie o tym co zama­wia­ją­cy rozu­mie. Dlaczego? Bo tyl­ko wte­dy autor tego tek­stu – tego wyma­ga­nia”, zama­wia­ją­cy – jest w sta­nie sam oce­nić jego sens i praw­dzi­wość” a tak­że przy­dat­ność. Gdzie tu rola ana­li­ty­ka? Analiza to spro­wa­dze­nie tych opi­sów do okre­ślo­nej struk­tu­ry wraz z okre­ślo­ną logi­ką – for­ma­li­za­cja. Rolą ana­li­ty­ka jest na tym eta­pie usu­wa­nie nie­jed­no­znacz­no­ści. Kolejny etap to dopro­wa­dze­nie doku­men­tu wyma­gań do spój­no­ści. Jeżeli uzna­my, że wyma­ga­nia to testy, to rolą ana­li­ty­ka jest wyspe­cy­fi­ko­wa­nie wyma­gań w posta­ci testów (przy­po­mi­nam, że wyma­ga­nia to warun­ki jakie musi speł­nić coś, by było przy­dat­ne do okre­ślo­ne­go celu), wszę­dzie tam, że wyma­ga­na jest jakaś logi­ka biz­ne­so­wa”, nale­ży ją tak­że udokumentować.

Jak słusz­nie powy­żej zauwa­żył autor cyta­tu, nale­ży pozwo­lić pro­gra­mi­stom wybrać naj­lep­szy spo­sób imple­men­ta­cji roz­wią­za­nia”, ale tu waż­na uwa­ga: imple­men­ta­cja to nie roz­wią­zy­wa­nie pro­ble­mów biz­ne­so­wych. Innymi sło­wy, pro­gra­mi­sta nie może dostać wyma­ga­nia w posta­ci sprze­daż towa­ru to pobra­nie go z maga­zy­nu”, bo po pierw­sze nie wie co to jest towar” po dru­gie nie zawsze jest to pobra­nie z maga­zy­nu. Należy mieć świa­do­mość, że towar” z per­spek­ty­wy pro­gra­mi­sty to struk­tu­ral­ny opis” i nie on ten opis powi­nien robić. Kto? Analityk.

Tak wiec powyż­sze, cyto­wa­ne user sto­ry raczej powin­no mieć postać: celem admi­ni­stra­to­ra opro­gra­mo­wa­nia jest śle­dze­nie zacho­wa­nia sys­te­mu i wychwy­ty­wa­nie zaist­nia­łych błę­dów w jego zacho­wa­niu, infor­ma­cje o błę­dach powi­nien otrzy­my­wać natych­miast” oraz dodat­ko­wo (robo­ta ana­li­ty­ka) powi­nien ist­nieć słow­nik biz­ne­so­wy z defi­ni­cją poję­cia błąd opro­gra­mo­wa­nia” oraz natych­miast”. Rolą pro­gra­mi­sty jest prze­ło­że­nie tego na język uży­te­go narzę­dzia (języ­ka pro­gra­mo­wa­nia) oraz zapew­nie­nie by powsta­łe opro­gra­mo­wa­nie było zgod­ne z ocze­ki­wa­ny­mi wyma­ga­nia­mi jako­ścio­wy­mi (wyma­ga­nie poza-funk­cjo­nal­ne: natychmiast).

Tak więc pro­gra­mi­sta imple­men­tu­je logi­kę biz­ne­so­wą, tę musi jed­no­znacz­nie udo­ku­men­to­wać ana­li­tyk, oraz zapew­nia uzgod­nio­ną jakość (wyma­ga­nia poza­funk­cjo­nal­ne). Ma więc dużo pra­cy… ale nie powi­nien podej­mo­wać prób wpły­wu na imple­men­to­wa­ną logi­kę biznesową.

miecz dwa ostrza dwustronny

Czyli np. jako sprze­daw­ca, dosta­ję od klien­tów zamó­wie­nia, na pod­sta­wie któ­rych muszę wysta­wiać fak­tu­ry VAT”, do tego ana­li­tyk doda, np. po ana­li­zie otrzy­ma­nej par­tii doku­men­tów, struk­tu­rę zamó­wie­nia i fak­tu­ry VAT oraz algo­rytm” wyli­cze­nia podatków.

Jeżeli pro­gra­mi­sta zaczy­na lepiej wie­dzieć” od zama­wia­ją­ce­go, for­su­jąc np. prost­szą imple­men­ta­cję, to zna­czy, że prze­kro­czył swo­je kom­pe­ten­cje, sam sobie – jako deve­lo­pe­ro­wi – robi krzyw­dę psu­jąc to opro­gra­mo­wa­nie bo klient i tak prę­dzej czy póź­niej na tych uprosz­cze­niach pole­gnie”. Rolą ana­li­ty­ka są tak­że ewen­tu­al­ne nego­cja­cje z zama­wia­ją­cym, uprosz­czeń lub roz­wi­nięć tego opi­su. Czy ana­li­tyk może być pra­cow­ni­kiem” dostaw­cy? Jak sądzicie?

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

Gdzie się realizują wymagania

Tym razem dość krót­ko ale zno­wu wzor­ce i dobre praktyki.

Bardzo czę­sto spo­ty­kam, pew­nie nie ja jeden, spe­cy­fi­ka­cje wyma­gań zawie­ra­ją­ce zapi­sy ocze­ki­wań użyt­kow­ni­ków”. Bardzo czę­sto sły­szę tak­że, że to przy­szły użyt­kow­nik opro­gra­mo­wa­nia powi­nien być źró­dłem wyma­gań. Nic bar­dziej błędnego.

Co nam powie słow­nik j.polskiego o wymaganiach?

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

Jest to bar­dzo zgrab­na defi­ni­cja. Zgodnie z logi­ką jeże­li jakieś poję­cie zastą­pi­my jego popraw­ną defi­ni­cją, zda­nie nie powin­no zmie­nić zna­cze­nia. Gdybyśmy więc powiedzieli:

Kupimy wyłącz­nie opro­gra­mo­wa­nie, któ­re speł­nia nasze wymagania.

to po takiej pod­mia­nie uzyskamy:

Kupimy wyłącz­nie opro­gra­mo­wa­nie, któ­re speł­nia nasze warun­ki, któ­rym musi ono odpowiadać.

Nie jest źle. Tak więc wyma­ga­nia na opro­gra­mo­wa­nie, to lista warun­ków, któ­rym musi ono odpo­wia­dać by było nam przydatne.

Najczęściej chy­ba moż­na się spo­tkać w pro­jek­tach z tak zwa­ny­mi wyma­ga­nia­mi funk­cjo­nal­ny­mi i poza funk­cjo­nal­ny­mi. Coraz czę­ściej moż­na spo­tkać też spe­cy­fi­ka­cje tak zwa­nych przy­pad­ków użycia.

Popatrzmy jed­nak naj­pierw na struk­tu­rę opro­gra­mo­wa­nia. Standardem archi­tek­tu­ry opro­gra­mo­wa­nia stał się wzo­rzec MVC ([[Model, View, Controller]]), tak go moż­na ogól­nie przedstawić:

MVC

Zanim zacznie­my spi­sy­wać wyma­ga­nia, war­to zro­zu­mieć z czym wal­czy­my. A wal­czy­my z tym, że opro­gra­mo­wa­nie to obec­nie roz­dzie­lo­ne: wygląd i treść inter­fej­su użyt­kow­ni­ka (View), logi­ka biz­ne­so­wa (Model), śro­do­wi­sko tech­no­lo­gicz­ne (Controller).

To co nazy­wa­my przy­pad­kiem uży­cia to inte­rak­cja użyt­kow­nik (aktor sys­te­mu) z sys­te­mem (opro­gra­mo­wa­nie). Tą meto­dą opi­su­je­my wyłącz­nie jeden, raczej rela­tyw­nie mało zna­czą­cy w pro­jek­cie two­rze­nia nowe­go opro­gra­mo­wa­nia, kom­po­nent. Jest on, przy­pa­dek uży­cia, jed­nak bar­dzo waż­ny przy wybo­rze goto­we­go opro­gra­mo­wa­ni bo tu defi­niu­je­my kon­kret­ną wyma­ga­ną Usługę Systemu (w goto­wym opro­gra­mo­wa­niu jej nie imple­men­tu­je­my, więc zbyt szcze­gó­ło­wy opis tu tyl­ko zaciem­nia problem).

Jeżeli tą usłu­gą ma być np. wysta­wia­nie fak­tur VAT” to czyn­ność ta jest dość dokład­nie opi­sa­na w prze­pi­sach i ryzy­ko, że nie otrzy­ma­my potrzeb­nej funk­cjo­nal­no­ści jest bli­skie zeru. Jeżeli jed­nak opis wyma­ga­nej usłu­gi sys­te­mu brzmi tak:

Wymaganie funk­cjo­nal­ne: sto­so­wa­nie funk­cji wyszu­ki­waw­czych ? wyszu­ki­wa­nie danych speł­nia­ją­cych okre­ślo­ne para­me­try, w tym według wię­cej niż jeden zada­nych kry­te­riów jed­no­cze­śnie. (cytat z doku­men­tu Opis Przedmiotu Zamówienia, w skró­cie OPZ, jed­ne­go z prze­tar­gów publicznych)

to konia z rzę­dem temu, kto mi powie co ten sys­tem ma tak na praw­dę robić i jak stwier­dzić, że zaku­pio­ny sys­tem to robi (cyto­wa­ny doku­ment OPZ jest w cało­ści napi­sa­ny w tym stylu).

Interfejsy: jeże­li napi­sze­my jedy­nie z czym się łączy­my np. enig­ma­tycz­ne: sys­tem ma pozwa­lać na wymia­nę danych z opro­gra­mo­wa­niem finan­so­wo-księ­go­wym, to tak na praw­dę wska­za­li­śmy tyl­ko, że taki trans­fer ma miej­sce, ale nic ponad to, a tu klu­czem są dane prze­ka­zy­wa­ne, o któ­rych ani sło­wa, i może się oka­zać, że jakaś wymia­na danych jest moż­li­wa (w zasa­dzie pra­wie zawsze jest) ale nie takich, któ­re są nam potrzeb­ne… czy­li tak na praw­dę wyma­ga­nie nie będzie speł­nio­ne i odkry­je­my to jed­nak za póź­no po po zaku­pie oprogramowania.

Uogólniając, cała nie­bie­ska część powyż­sze­go dia­gra­mu to śro­do­wi­sko tech­no­lo­gicz­ne, z regu­ły pre­de­fi­nio­wa­ne jako tak zwa­ny fra­me­work (szkie­let opro­gra­mo­wa­nia), któ­re­go raczej się nie zmie­nia a używa.

Najciekawsze jest to, że opro­gra­mo­wa­nie słu­ży w głów­nej mie­rze do prze­twa­rza­nia danych. Coś daje­my na wej­ściu i cze­goś ocze­ku­je­my. Co tu jest istot­ne? Opis tego co jest prze­twa­rza­ne ale przede wszyst­kim regu­ły tego prze­twa­rza­nia! Przypadek uży­cia, popraw­nie opi­sa­ny, to tak­że dane wej­ścio­we i dane wyj­ścio­we, ale gdzieś powin­no być napi­sa­ne jak”?

Na powyż­szym dia­gra­mie kolo­rem zie­lo­nym ozna­czo­no tak zwa­ny model dzie­dzi­ny (Model z wzor­ca MVC). To miej­sce, w któ­rym opro­gra­mo­wa­nie prze­twa­rza”. To tu tkwi sed­no wyma­gań”. Co cie­ka­we, popraw­nie (zno­wu dobre prak­ty­ki) zapro­jek­to­wa­ne opro­gra­mo­wa­nie całą logi­kę i przy­pad­ki uży­cia reali­zu­je wła­śnie w tym kom­po­nen­cie. Reszta to tyl­ko pozba­wio­ne logi­ki biz­ne­so­wej (tak, tu ich nie powin­no być) inter­fej­sy (użyt­kow­ni­ka i komunikacyjny).

Więc np. wyma­ga­nie sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” (tak­że cytat z pew­nej spe­cy­fi­ka­cji sys­te­mu CRM) jest pustym stwier­dze­niem. Po pierw­sze jak te raba­ty są nali­cza­ne, po dru­gie czy aby na pew­no mecha­nizm pozwa­la na dowol­ne raba­ty”… Jak to opi­sać? Tu powin­ny się poja­wić np. tabli­ce decy­zyj­ne a nie lako­nicz­ne dowol­ne rabaty”.

Na zakoń­cze­nie uwa­ga: jeże­li pla­nu­je­my kupić goto­we opro­gra­mo­wa­nie, to ono już (gdzieś tam) ist­nie­je, i spe­cy­fi­ko­wa­nie szcze­gó­łów opi­su­ją­cych dokład­nie ele­men­ty pra­cy z inter­fej­sem użyt­kow­ni­ka i enig­ma­tycz­ne opi­sy tego jak sys­tem liczy”, jest bez­war­to­ścio­we. Raczej wywo­ła listę tak zwa­nych kasto­mi­za­cji (zwa­nych gdzie­nie­gdzie zabój­ca­mi pro­jek­tów :)). Tak jed­nak wła­śnie wyglą­da­ją naj­czę­ściej spe­cy­fi­ka­cje pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków: opi­szą oni to z czym się sty­ka­ją i co zna­ją ale w ogó­le nie opi­szą wnę­trza, któ­re­go naj­czę­ściej po pro­tu nie rozu­mie­ją (i nie muszą bo to nie ich rola), wte­dy spe­cy­fi­ka­cje sys­te­mów CRM pisa­ne ręka­mi przy­szłych użyt­kow­ni­ków – np. sprze­daw­ców – zawie­ra­ją wła­śnie bez­war­to­ścio­we zapi­sy w rodza­ju: sys­tem powi­nien pozwa­lać na budo­wa­nie dowol­nych raba­tów sprze­da­ży do sta­łych klien­tów” a nie zawie­ra­ją opi­su jak te raba­ty wyliczać.

Odpowiadając na tytu­ło­we pyta­nie: wyma­ga­nia (funk­cjo­nal­ne) reali­zu­ją się w mode­lu dzie­dzi­ny sys­te­mu, któ­re­go nie zawie­ra więk­szość zna­nych spe­cy­fi­ka­cji wyma­gań… a warun­kiem popraw­ne­go wybo­ru opro­gra­mo­wa­nia są ocze­ki­wa­nia co do efek­tów przetwarzania.