Prawo a wymagania …

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w doku­men­ta­cji wyma­gań”. Jakim wyma­ga­niem jest zgod­ność z obo­wią­zu­ją­cym pra­wem”? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wymagania.

Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspekty.

Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z prawem”.

Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ani nie powin­no pozwa­lać na łama­nie pra­wa”. Tu jed­nak wie­lu uwa­ża, że zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność”. Coś w tym jest, war­to jed­nak zosta­wić włącz­nik”. Typowym przy­kła­dem tego pro­ble­mu jest moż­li­wość two­rze­nia ujem­nych sta­nów maga­zy­no­wych (sprze­daż tego cze­go się nie ma, jest nie­zgod­na z pra­wem). Budzi to wie­le kon­tro­wer­sji na eta­pie ana­li­zy wyma­gań”, ale oso­bi­ście uwa­żam ujem­ne sta­ny maga­zy­no­we, i wie­lu ludzi jakich spo­ty­kam w pro­jek­tach też, za pato­lo­gię i nie­doj­rza­łość do pro­wa­dze­nia biz­ne­su. Jednak włącz­nik w wie­lu roz­wią­za­niach jest :).

Czym jest wyma­ga­nie? Jak je definiujemy?

Wymagania w sto­sun­ku do opro­gra­mo­wa­nia dzie­li się naj­czę­ściej na funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Wymaganie funk­cjo­nal­ne to usłu­ga sys­te­mu (opro­gra­mo­wa­nie wspie­ra nas w wyko­ny­wa­niu jakiejś czyn­no­ści), mogą być tu wydzie­lo­ne wyma­ga­nia przej­ścio­we (np. funk­cjo­nal­no­ści potrzeb­ne tyl­ko na czas migra­cji ze sta­re­go sys­te­mu). Wymagania poza-funk­cjo­nal­ne to ogra­ni­cze­nia czy­li wyma­ga­nia jako­ścio­we lub dzie­dzi­no­we. Jakość to nie­za­wod­ność, bez­pie­czeń­stwo, wydaj­ność. Dziedzinowe wyma­ga­nia to np. zdol­ność opro­gra­mo­wa­nia do reali­za­cji kon­kret­nej logi­ki biz­ne­so­wej, sto­pień odwzo­ro­wa­nia rze­czy­wi­sto­ści – zgod­ność z tą rze­czy­wi­sto­ścią (np. ujem­ny stan maga­zy­no­wy to nie­rze­czy­wi­sty stan, opis pro­duk­tu to struk­tu­ra, któ­rą nale­ży odwzo­ro­wać w sys­te­mie). Wymagania wyni­ka­ją­ce z aktów praw­nych to wyma­ga­nia dzie­dzi­no­we (ogra­ni­czo­ne zacho­wa­nia obiek­tów biz­ne­so­wych) i ograniczenia.

Kiedy jakie wymagania?

Specyfikując wyma­ga­nia war­to pamię­tać po pierw­sze o zakre­sie pro­jek­tu, a po dru­gie o tym czy spe­cy­fi­ku­je­my wyma­ga­nia na pro­dukt goto­wy (tak zwa­ny [[COTS]] np. pakiet ERP czy CRM), czy na sys­tem dedy­ko­wa­ny. Wymagania wyni­ka­ją­ce z dzie­dzi­ny sys­te­mu (tu pra­wo) powin­ny być udo­ku­men­to­wa­ne jako coś co będzie imple­men­to­wa­ne” ale czy zawsze?

Swego cza­su pisa­łem o tym, że pod­sta­wo­wy model w ana­li­zie, model przy­pad­ków uży­cia, zawie­ra abs­trak­cję sys­te­mu oraz jego użyt­kow­ni­ków: aktorów.

Jednym z klu­czo­wych ele­men­tów spe­cy­fi­ka­cji jest w moich pro­jek­tach spe­cy­fi­ka­cja akto­rów. Jak czę­sto spo­ty­ka­cie Państwo pro­jek­tan­ta, któ­ry opra­co­wu­je listę akto­rów sys­te­mu zawie­ra­ją­cą ich cha­rak­te­ry­sty­kę, w szcze­gól­no­ści wie­dzę i wyma­ga­ne umie­jęt­no­ści? W czym pro­blem? Zasadnicze pyta­nie: pra­wo ma znać aktor czy czy sys­tem”? Kto ma nad­zo­ro­wać jego prze­strze­ga­nie? Prawie każ­dy czło­wiek ma w domu nóż, gdzie jest zaim­ple­men­to­wa­ne nie zabijaj”?

Czy posta­wio­no wyma­ga­nie: sys­tem nie może pozwo­lić na wyko­na­nie ope­ra­cji nie­zgod­nej z pra­wem? Kto lub co ma reali­zo­wać wyma­ga­nia zgod­no­ści z pra­wem”? Jeżeli aktor, zapi­su­je­my to w cha­rak­te­ry­sty­ce akto­rów (czło­wiek musi prze­strze­gać pra­wa i odpo­wia­da za jego nie przestrzeganie).

Jeżeli cho­dzi o pro­jek­to­wa­ny sys­tem, spra­wa się kom­pli­ku­je, gdyż pra­wo to ogra­ni­cze­nia i nie powin­ny one być szkie­le­tem tego sys­te­mu a co naj­wy­żej dodat­ko­wy­mi para­me­tra­mi. Osobiście hoł­du­ję zasa­dzie her­me­ty­za­cji w pro­jek­tach, to co nazy­wa­my pra­wem opi­su­je jako dedy­ko­wa­ne kla­sy dzie­dzi­no­we mają­ce peł­ną wie­dzę o tych ogra­ni­cze­niach praw­nych (tak­że wewnętrz­nych zarzą­dze­niach w fir­mie itp.). Tą meto­dą oddzie­lam zmien­ność pra­wa od szkie­le­tu sys­te­mu, dzię­ki cze­mu zmia­ny praw­ne nie powo­du­ją lawi­no­wych zmian w goto­wym już oprogramowaniu.

Druga korzyść to swo­bo­da decy­do­wa­nia jaką wie­dzę” ma mieć aktor a jaką sys­tem”. Prostym przy­kła­dem jest usłu­ga sys­te­mu (przy­pa­dek uży­cia) jaką jest wysta­wia­nie fak­tur. Inaczej sys­tem powi­nien zacho­wać się gdy fak­tu­rę wysta­wia np. Główny Księgowy (ma peł­ną wie­dzę o tym co robi) i moż­na dać takiej oso­bie dużą swo­bo­dę kształ­to­wa­nia tre­ści takie­go doku­men­tu (raczej poprze­sta­nie­my na nie­skom­pli­ko­wa­nej wali­da­cji pod­sta­wo­wej logi­ki obli­czeń). Jednak wysta­wie­nie fak­tu­ry przez zwy­kłe­go” pra­cow­ni­ka dzia­łu sprze­da­ży, powin­no być obło­żo­ne wie­lo­ma zabez­pie­cze­nia­mi, regu­ła­mi, np. towar wyłącz­nie na pod­sta­wie zamó­wie­nia, tyl­ko wybra­ne podat­ki, itp.

W przy­pad­ku sys­te­mu goto­we­go, nie widzę sen­su pro­wa­dze­nia żmud­nej ana­li­zy aktów praw­nych, wyko­nał ją (zakła­dam, że tak) dostaw­ca – twór­ca, goto­we­go opro­gra­mo­wa­nia np. ERP i ocze­ku­je od nie­go tej zgod­no­ści z pra­wem (i inny­mi nor­ma­mi czy stan­dar­da­mi). Unikamy w ten spo­sób nad­mier­nych kosz­tów (pra­co­chłon­ność) spe­cy­fi­ka­cji wyma­gań na goto­we opro­gra­mo­wa­nie. Deklaracja dostaw­cy (np. sys­tem jest zgod­ny z usta­wą o rachun­ko­wo­ści, podat­ku VAT itp…) jest wystar­cza­ją­cym do wybo­ru tego opro­gra­mo­wa­nia (i tak nie spraw­dzi­my tego w roz­sąd­nie krót­kim cza­sie pod­czas wybo­ru opro­gra­mo­wa­nia) a potem powo­dem do ewen­tu­al­nej rekla­ma­cji. Wykonanie szcze­gó­ło­wej listy ogra­ni­czeń praw­nych wca­le takiej dekla­ra­cji dostaw­cy nie ulep­szy”. Gdy zechce, zade­kla­ru­je tę zgod­ność tak czy tak…

Więc jak?

Ograniczenia praw­ne (naka­zy i zaka­zy) to regu­ły ana­lo­gicz­ne do biz­ne­so­wych (regu­ły biz­ne­so­we to wewnętrz­ne naka­zy i zaka­zy, wewnętrz­ne pra­wo fir­my). Na eta­pie ana­li­zy biz­ne­so­wej nale­ży je opi­sać i sko­ja­rzyć z czyn­no­ścia­mi (tymi, któ­re są ogra­ni­cza­ne tymi regułami):

Stosuję nastę­pu­ją­cy spo­sób uwzględ­nia­nia pra­wa w wyma­ga­niach: trak­to­wa­nie pra­wa jako odręb­nej spe­cy­fi­ka­cji reguł biz­ne­so­wych. Powstaje lista w rodza­ju: ID regu­ły, jej defi­ni­cja, opis, źró­dło … Reguły biz­ne­so­we moż­na potem koja­rzyć (śla­do­wać) z czyn­no­ścia­mi w pro­ce­sach i z kla­sa­mi w mode­lu dzie­dzi­ny. Jestem zwo­len­ni­kiem trak­to­wa­nia takich reguł wła­śnie nie, jak wyma­gań (pra­wo to nie usłu­ga sys­te­mu a ogra­ni­cze­nie swo­bo­dy jego uży­cia) a jak ogra­ni­czeń w pro­ce­sach. Prawo może się zmie­niać, sys­tem powi­nien być na to odporny…

Mały cytat z opi­su meto­dy­ki jaką stosuję:

Praktycznie każ­da orga­ni­za­cja, poza pra­wem, któ­re­go musi prze­strze­gać, ma wła­sne wewnętrz­ne regu­la­cje. Ich licz­ba jest zależ­na od stop­nia for­ma­li­za­cji pra­cy. W przy­pad­kach gdy regu­la­cje te były two­rzo­ne lata­mi, bar­dzo czę­sto ich licz­ba jest więk­sza niż wyma­ga tego sytu­acja. Bardzo czę­sto poszcze­gól­ne regu­la­cje bywa­ją sprzecz­ne lub zamiast regu­ły spe­cy­fi­ku­ją jej wariant (np. zamiast okre­ślić ogól­nie ist­nie­nie pro­gu podej­mo­wa­nia przez kadry kie­row­ni­cze decy­zji o kosz­tach i spo­sób ich okre­śla­nia, spe­cy­fi­ku­ją osob­no sta­no­wi­ska i kon­kret­ne kwo­ty, nie raz sprzeczne).

Reguły biz­ne­so­we mogą być obra­zo­wa­ne na dia­gra­mach. Specyfikowane są w posta­ci listy zawie­ra­ją­cej sym­bol i nazwę regu­ły oraz jej for­mu­łę w posta­ci: ?dla każ­de­go ??, ?jeże­li ? to ??, ?zawsze gdy? nale­ży ?? itp. Reguły biz­ne­so­we two­rzy się na bazie pojęć budo­wa­ne­go Słownika pojęć, któ­ry jest inte­gral­ną czę­ścią projektu.

WARTOŚĆ DODANA

Podstawową korzy­ścią z wyod­ręb­nie­nia reguł biz­ne­so­wych i słow­ni­ka pojęć jest upo­rząd­ko­wa­nie słow­nic­twa w doku­men­ta­cji i uczy­nie­nie jej jed­no­znacz­ną oraz wery­fi­ka­cja ewen­tu­al­nych sprzecz­no­ści regu­la­cji wewnętrz­nych (Zarządzeń, Prawa). Powoływanie się na Reguły biz­ne­so­we na mode­lach pro­ce­sów biz­ne­so­wych, pozwa­la zacho­wać ich pro­sto­tę nie tra­cąc szcze­gó­ło­wo­ści wie­dzy o pro­ce­sach. Tak wyko­na­na doku­men­ta­cja pro­ce­sów nie wyma­ga czę­stej i kosz­tow­nej aktu­ali­za­cji, z regu­ły aktu­ali­zo­wa­ne są pro­ce­du­ry i regu­ły biz­ne­so­we, na któ­re mode­le pro­ce­sów się powołują.

(źr. SPOSÓB PROWADZENIA I DOKUMENTOWANIA ANALIZ BIZNESOWYCH I PROJEKTOWANIA SYSTEMÓW, Jarosław Żeliński)

Tak więc akty praw­ne to zaka­zy i naka­zy, regu­ły biz­ne­so­we. Oprogramowanie, zależ­nie od przy­ję­tej kon­wen­cji, nie powin­no ogra­ni­czać ani nawet utrud­niać postę­po­wa­nia zgod­ne­go z pra­wem, może też poja­wić się ocze­ki­wa­nie by nie pozwa­la­ło łamać pra­wa. Szczegółowa ana­li­za aktów praw­nych, w moich oczach, ma sens gdy pro­jek­tu­je­my opro­gra­mo­wa­nie. Gdy sta­wia­my wyma­ga­nia przed już ist­nie­ją­cym opro­gra­mo­wa­niem, jeże­li zakła­da­my że kupi­my goto­we, wystar­czy wyma­gać zgod­no­ści z pra­wem w obsza­rze sto­so­wa­nia opro­gra­mo­wa­nia. Jeżeli np. opro­gra­mo­wa­nie ma pozwa­lać na wysta­wia­nie fak­tur to zna­czy, że powin­no być moż­li­we wysta­wie­nie każ­dej fak­tu­ry prze­wi­dzia­nej pra­wem w spo­sób zgod­ny z nim. Możemy dodat­ko­wo zażą­dać by nie było moż­li­we wysta­wie­nie fak­tu­ry nie­zgod­nej z prawem.

Podsumowanie

Podstawą koja­rze­nia pojęć i ich śla­do­wa­nia są defi­ni­cje tych pojęć: muszą być zgod­ne, lub cał­ko­wi­cie się w sobie zawie­rać. Jeżeli czyn­ność jest szer­szym poję­ciem niż przy­pa­dek uży­cia, przy­pa­dek uży­cia jest wywo­dzo­ny (mapo­wa­ny) z czyn­no­ści w pro­ce­sie, przy­pa­dek uży­cia nie powi­nien ozna­czać nicze­go co nie mie­ści się w poję­ciu czyn­ność”.

W pro­ce­sie mamy czyn­no­ści, wyma­ga­nia funk­cjo­nal­ne to usłu­gi sys­te­mu: jego przy­pad­ki uży­cia. Oznacza to, że nie jest wyma­ga­niem funk­cjo­nal­nym to, co nie jest przy­pad­kiem uży­cia sys­te­mu ([[zasa­da wyłą­czo­ne­go środ­ka w logi­ce]]). Wymagania poza-funk­cjo­nal­ne to pozo­sta­łe, nie będą­ce usłu­gą sys­te­mu, jego cechy. Pozostają więc jakość i logi­ka wewnętrz­nej budo­wy. Śladowanie to wyglą­da np. tak:

Czynność jest mapo­wa­na na przy­pa­dek uży­cia. Rola w pro­ce­sie na akto­ra. Przypadek uży­cia ma odpo­wia­da­ją­cą mu kla­sę usłu­go­wą (zarzą­dza świad­cze­niem tej usłu­gi). Jeżeli ist­nie­ją jakieś regu­ły i ogra­ni­cze­nia, są one imple­men­to­wa­ne jako osob­ne kla­sy skła­do­we kla­sy usłu­go­wej. Możliwe jest też zaim­ple­men­to­wa­nie odręb­ne­go moto­ra reguł biz­ne­so­wych” jeże­li sys­tem wyma­ga ich bar­dziej wyra­fi­no­wa­nej obsługi.

Tak więc zgod­ność opro­gra­mo­wa­nia z pra­wem to jego wyma­ga­na cecha (wła­ści­wość) a nie funkcjonalność.

Więcej o regu­łach w arty­ku­le: Business rules con­cept… oraz arty­ku­le Reguły biz­ne­so­we…

Inne artykuły na podobny temat

Komentarze

  1. Tadeusz Retmańczyk 13 lutego 2013 at 13:44

    W arty­ku­le z 12 czerw­ca 2012 roku stwier­dził Pan w swo­im arty­ku­le Prawo a wyna­ga­nia” iż two­rze­nie sta­nów maga­zy­no­wych a wiec i mozli­wośc sprze­daż jest nie­zgod­na z pra­wem. Czy mógł­by Pan, jeże­li mozna okre­ślić czy ta nie­zgod­nośc doty­czy kon­kret­nej lite­ry prawa?
    Pozdrawiam
    Tadeusz Retmańczyk

    • Jarek Żeliński 13 lutego 2013 at 14:12

      Chodzi rozu­miem, o ujem­ne sta­ny maga­zy­no­we? Wystawienie doku­men­tu poświad­cza­ją­ce­go doko­na­nie sprze­da­ży towa­ru (fak­tu­ra VAT), któ­re­go się nie ma (stan zero w maga­zy­nie) to poświad­cze­nie nie­praw­dy co już jest łama­niem pra­wa. Jest nie­zgod­ne z usta­wą o podat­ku VAT (jak go w takiej sytu­acji legal­nie poli­czyć?). Nie ma para­gra­fu mówią­ce­go nie wol­no mieć sta­nu ujem­ne­go na maga­zy­nie”, ogól­nie poświad­cza­nie nie­praw­dy jest łama­niem pra­wa, a tym są nie­zgod­ne z fak­ta­mi zapi­sy księ­go­we (lub ich brak). Ujemne sta­ny maga­zy­no­we w opro­gra­mo­wa­niu maga­zy­no­wym to wyłącz­nie lekar­stwo” na chęć sprze­da­nia (zafak­tu­ro­wa­nia) towa­ru, zanim zosta­nie przy­ję­ty na maga­zyn. Powodem są naj­czę­ściej naci­ski sprze­daw­ców w zaba­ła­ga­nio­nej fir­mie. Niektórzy księ­go­wi bro­nią się, że dosta­wa kom­pen­su­je ten minus” i czas tej chwi­lo­wej nie­zgod­no­ści” jest krót­ki, ale: for­mal­nie data przy­ję­cia nie może być póź­niej­sza niż data sprze­da­ży, ma więc miej­sce anty­da­to­wa­nie doku­men­tu przy­ję­cia. Po dru­gie jakie­kol­wiek zda­rze­nie zwią­za­ne ze sprze­da­żą (data zda­rze­nia, np. kra­dzież, inne nad­uży­cia) rodzą ryzy­ko wyja­wie­nia tej chwi­lo­wej” sytu­acji. Rzecz w tym, że zapi­sy księ­go­we nie mogą mieć momen­tów” nie­zgod­nych z pra­wem. Idąc dalej tym tro­pem, rapor­to­wa­nie z reje­strów zawie­ra­ją­cych ujem­ne sta­ny” czy­ni te rapor­ty bezużytecznymi…

      Na pro­blem ten zwró­ci­łem tak­że uwa­gę tu: http://​it​-con​sul​ting​.pl/​a​u​t​o​i​n​s​t​a​l​a​t​o​r​/​w​o​r​d​p​r​e​s​s​/​2​0​1​3​/​0​2​/​0​7​/​a​n​a​l​i​t​y​k​-​t​o​-​n​i​e​-​d​y​k​t​a​f​on/

  2. jacek2v 12 lipca 2013 at 20:58

    W jed­nym z poprzed­nich arty­ku­łów napi­sał Pan, że: pra­cow­nik” jako czło­wiek to nie to samo co pra­cow­nik” w sys­te­mie, czy­li powin­no być kar­to­te­ka pra­cow­ni­ka” – podob­nie z np. odwzo­ro­wa­niem maga­zy­nu. Spodobało mi się to podej­ście. W kon­se­kwen­cji tego, moż­li­we są sta­ny maga­zy­no­we ujem­ne, ponie­waż nie są one bez­po­śred­nim odwzo­ro­wa­niem fizycz­no­ści”. Podobnie doty­czy to też zgod­no­ści opro­gra­mo­wa­nia z prawem.

    • Jarek Żeliński 12 lipca 2013 at 21:59

      Oprogramowanie, podob­nie jak papier, zdzier­ży wszyst­ko i to jest praw­da, war­to jed­nak nie zapo­mi­nać, że ono słu­ży do zarzą­dza­nia tym co real­ne ;). W opro­gra­mo­wa­niu dekla­ru­je­my aser­cje, to regu­ły któ­re czy­nią je przy­dat­niej­szym :). Co zro­bi wła­ści­ciel fir­my, jeże­li tra­fi go kon­tro­la z Urzędu skar­bo­we­go i wykry­je nie­zgod­ność danych np. z Ustawą o podat­ku VAT? 

    • jacek2v 12 lipca 2013 at 23:45

      Zależnie od sytu­acji i moż­li­wo­ści wła­ści­cie­la podej­mie on decy­zję, któ­rą uwa­ża za najlepszą 🙂
      Zaznaczam, że mówi­my o opro­gra­mo­wa­niu zgod­nym z wyma­ga­nia­mi właściciela.

    • Jarek Żeliński 13 lipca 2013 at 10:50

      Największym dyle­ma­tem jaki nie raz mam jest to, do jakie­go stop­nia takie wyma­ga­nia nale­ży speł­niać. Jest gdzieś gra­ni­ca, któ­rej prze­kro­cze­nie czy­ni z wyko­naw­cy najem­ni­ka mor­der­cę. Pytanie, czy najem­nik mor­der­ca jest roz­grze­szo­ny tym, że wyko­ny­wał zle­ce­nie swo­je­go klien­ta? W tym przy­pad­ku, zgod­nie z pra­wem win­ni są obaj, w IT już nie ma takie­go pra­wa, sami je two­rzy­my zawie­ra­jąc umo­wy… Tu chy­ba nie ma pro­stej odpo­wie­dzi… Ja oso­bi­ście sto­su­ję zasa­dę, w któ­rej w wyma­ga­niach «wpi­su­je aser­cję”, komen­tu­je ją, i pozo­sta­wiam zama­wia­ją­ce­mu moż­li­wość jej wyłą­cze­nia”, zale­cam jedy­nie by była to opcja na ekra­nie a nie usu­nię­cie z pro­jek­tu”. To moim zda­niem jest naj­uczciw­sze dla obu stron podejście.

  3. jacek2v 13 lipca 2013 at 11:35

    Myślę, że IBM sprze­da­jąc kom­pu­te­ry nazi­stom w począt­kach ubie­głe­go wie­ku był bli­sko gra­ni­cy najem­ni­ka mor­der­cy”. Dzisiaj jeśli inten­cją funk­cjo­nal­no­ści nie jest oszu­ki­wa­nie, ale np. uela­stycz­nie­nie – życie bar­dzo trud­no wpi­su­je się w sztyw­ne pro­ce­du­ry – to moim zda­niem moż­na z czy­stym sumie­niem takie funk­cje tworzyć.
    Zresztą to nie jest tyl­ko pro­blem infor­ma­ty­ki. Np. pro­du­cen­ci noży dobrze sobie zda­ją spra­wę, że moż­na ich pro­duk­ty uży­wać do zabi­ja­nia – wszyst­ko zale­ży od inten­cji pro­du­ku­ją­ce­go i używającego.

    • Jarek Żeliński 13 lipca 2013 at 20:36

      Przykład z nożem jak naj­bar­dziej słusz­ny, jed­nak pamię­taj­my, że np. na pokład samo­lo­tu z zasa­dy nie moż­na jed­nak wnieść nicze­go co ma ostrze dłuż­sze niż 6 cm, wiec jed­nak pew­ne regu­ły są usta­la­ne i prze­strze­ga­ne. Innym wyraź­niej­szym przy­kła­dem tego, że jed­nak pew­ne regu­ły są nie tyl­ko uzna­wa­ne ale tak­że powsta­je opro­gra­mo­wa­nie by to kon­tro­lo­wać są apli­ka­cje wykry­wa­ją­ce pew­ne nad­uży­cia czy­li sys­te­my typu fraud detec­tion”. Tak więc zga­dzam się z tym, że zama­wia­ją­cy jest doro­sły i zna (nale­ży tak zało­żyć) kon­se­kwen­cje, ale nie zawsze. Znam dyrek­to­rów finan­so­wych dużych firm, któ­rzy byli zasko­cze­ni tym, że stan ujem­ny w maga­zy­nie jest nie­do­pusz­czal­ny(!). Pytanie brzmi: jaka ana­li­za powin­na wyko­na­na na począt­ku pro­jek­tu? Czy ana­li­za biz­ne­so­wa, w któ­rej tre­ści nie znaj­dzie się reko­men­da­cja o poten­cjal­nej szko­dli­wo­ści roz­wią­za­nia jest dobra ana­li­zą? Czy dostaw­ca opro­gra­mo­wa­nia pozwa­la­ją­ce­go na nad­uży­cia nie sta­wia się w pozy­cji rów­nej ze sprze­daw­cą bro­ni zaopa­tru­ją­cym terrorystów?

  4. jacek2v 14 lipca 2013 at 11:20

    Przed lub w trak­cie ana­li­zy zawsze moż­na zapy­tać: Do cze­go jest to potrzeb­ne? Jaki cel chce­cie osią­gnąć? Czy zda­je­cie sobie spra­wę, że to może być nie­zgod­ne z przepisami?
    Zależnie od odpo­wie­dzi, moż­na wte­dy pod­jąć decy­zję zgod­ną z wła­sny­mi przekonaniami.

    • Jarek Żeliński 15 lipca 2013 at 07:28

      I to jest chy­ba wła­ści­we podsumowanie 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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