Mega projekty czyli jak zjeść słonia

Ku moje­mu zasko­cze­niu dość czę­sto dosta­ję pyta­nia o moż­li­wość zaan­ga­żo­wa­nia się w roli ana­li­ty­ka np. na rok na warun­kach: 100% cza­su na miej­scu u klien­ta a wyni­kiem ma być spe­cy­fi­ka­cja wyma­gań na opro­gra­mo­wa­nie, któ­re­go reali­za­cja jest pla­no­wa­na na np. kolej­ne 5 lat. Nie ma to moim zda­niem żad­ne­go sen­su i nie anga­żu­je się w takie pro­jek­ty. Ale po kolei.

Już w roku chy­ba 2003 robi­łem ana­li­zę ryzy­ka dużych i dłu­gich pro­jek­tów, celem była oce­na praw­do­po­do­bień­stwa i kosz­tów wpro­wa­dza­nia zmian do zakre­su pro­jek­tu. Jak nie trud­no się domy­śleć, jest to – zmia­ny zakre­su – naj­bar­dziej nie­chcia­na rzecz w każ­dym pro­jek­cie. Materiał ten był pre­zen­to­wa­ny na jed­nej z kon­fe­ren­cji doty­czą­cych wdra­ża­nia sys­te­mów ERP.

Co spo­wo­do­wa­ło moje zain­te­re­so­wa­nie tym pro­ble­mem? To co każ­dy w tej bran­ży widział chy­ba naj­mniej raz w życiu: róż­ni­ca pomię­dzy pier­wot­ną spe­cy­fi­ka­cją a osta­tecz­nym pro­duk­tem. W dużych pro­jek­tach czę­sto te dwa sta­ny nie mają z sobą zbyt wie­le wspól­ne­go! Więc poja­wia się pyta­nie: po co robić wiel­ką ana­li­zę i doku­men­ta­cję sko­ro więk­szość tej doku­men­ta­cji, roz­dział po roz­dzia­le, lądu­je w koszu za spra­wą zarzą­dza­nia zmianą”?

Jakie są naj­częst­sze pro­ble­my w nie­uda­nych pro­jek­tach? 70% to zmia­ny zakre­su pro­jek­tu, (Raport Jama Sofware ? O wyma­ga­niach).

Popatrzmy na to:

Ryzyko projektu 1

Analiza i spe­cy­fi­ko­wa­nie wyma­gań to tak na praw­dę pro­gno­za mówią­ca, że to co teraz pro­jek­tu­je­my będzie w przy­szło­ści, w dniu odda­nia do użyt­ku, potrzeb­ne w takiej for­mie w jakiej wła­śnie to pro­jek­tu­je­my. Jak wie­my, pro­gno­zy są tym więk­szym błę­dem obar­czo­ne i bar­dziej w przy­szłość wybie­ga­ją. Powyższy dia­gram to typo­wy mega­pro­jekt. Linia prze­ry­wa­na obra­zu­je pew­ną hipo­te­tycz­ną gra­ni­cę, powy­żej któ­rej ryzy­ko błęd­nej pro­gno­zy prze­kra­cza np. 50% (czy­li kla­sycz­ny rzut monetą).

Innymi sło­wy, roz­po­czy­na­jąc mega­pro­jekt mamy nie­mal­że pew­ność, że jego zakres ule­gnie zmia­nie czy­li cała pra­ca powy­żej tej linii prze­ry­wa­nej pój­dzie do kosza (na koszt spon­so­ra projektu ;)).

W natu­ral­ny spo­sób nasu­wa się wnio­sek: nie nale­ży robić nic ponad tę prze­ry­wa­ną linię. Wtedy otrzy­ma­my taki diagram:

Ryzyko projektu 2

Robimy tyl­ko to co z ryzy­kiem bli­skim zera zosta­nie zaim­ple­men­to­wa­ne bez zmian. Jak? Pierwszy etap to ana­li­za pro­ble­mu i pro­jek­to­wa­nie archi­tek­tu­ry cało­ści – model kom­po­nen­tów. Jest to jakaś logi­ka sys­te­mu na dość wyso­kim pozio­mie abs­trak­cji ale dają­ca się prze­te­sto­wać. Stanowi ona pod­sta­wę dal­szej pra­cy nad każ­dym kom­po­nen­tem osob­no (kolej­ne eta­py). Uszczegóławianie wyma­gań odkła­da­my na ostat­ni moment”. W ten spo­sób kwar­tał po kwar­ta­le” dopre­cy­zo­wu­je­my wyma­ga­nia na kolej­ny etap i reali­zu­je­my go. Co zysku­je­my? Nie wyrzu­ca­my do kosza nad­mier­nie szcze­gó­ło­wej i roz­le­głej doku­men­ta­cji wyma­gań, nie pono­si­my koszów pro­jek­to­wa­nia cze­goś co może wyle­cieć” z zakre­su za pół roku z powo­dów np. zmian na ryn­ku, może­my w dowol­nym momen­cie zmie­nić kolej­ne pla­no­wa­ne kom­po­nen­ty, usu­nąć jed­ne i opra­co­wać nowe bez ryzy­ka zbęd­nych kosztów.

Pierwszy etap ma pew­ną cechę: two­rzy (taki ma cel) jeden wspól­ny model wszyst­kich pro­jek­tów dla danej orga­ni­za­cji o wdzięcz­nej nazwie Architektura Korporacyjna. Kolejne kon­kret­ne kom­po­nen­ty archi­tek­tu­ry IT to kolej­ne pro­jek­ty, cechu­ją­ce się zro­zu­mia­nym umiej­sco­wie­niem w cało­ści orga­ni­za­cji i wia­ry­god­nym, spój­nym z cało­ścią zakresem.

Dlatego z regu­ły nie mają sensu:

  1. wdro­że­nia depar­ta­men­to­we ode­rwa­ne od resz­ty (np. Dział Handlowy sobie fun­du­je sam sys­tem CRM),
  2. pro­jek­ty trwa­ją­ce dłu­żej niż trzy kwar­ta­ły (ostat­ni kwar­tał to kolej­ne pla­no­wa­nie budże­tu na kolej­ny rok czy­li pla­no­wa­nie zmian),
  3. mega pro­jek­ty ERPII czy­li all in one” dla fir­my w ramach jed­ne­go projektu.

Więc jak zjeść sło­nia by się nie udła­wić? Powoli i po kawał­ku… I nie zapo­mi­naj­my, że wyzwa­niem może być nie tyle nowe opro­gra­mo­wa­nie co zmia­na nawy­ków ludzi… a nie ma nic gor­sze­go niż pla­no­wa­nie nowe­go opro­gra­mo­wa­nia dla sta­rych nawy­ków bo po co to robić?

Pamiętajmy, że zarzą­dza­nie zakre­sem pro­jek­tu jest tym kosz­tow­niej­sze im wię­cej szcze­gó­łów ten zakres posia­da. Projekt o 30 wyma­ga­niach vs. pro­jekt o 300 wyma­ga­niach to nie pro­jekt o 10-krot­nie więk­szym kosz­cie, ta róż­ni­ca będzie znacz­nie więk­sza (pomi­jam to jak w ogó­le zde­fi­niu­je­my wymaganie).

Tak więc prze­cięt­ny pro­jekt to dla ana­li­ty­ka pra­ca na nie wię­cej niż kwar­tał (mniej wię­cej). Jak ja opi­sać wyma­ga­nia na sys­te­my ERP? Nie są to set­ki szcze­gó­ło­wych wyma­gań, bo to nie ma sen­su. To opis archi­tek­tu­ry kor­po­ra­cyj­nej wraz z zesta­wem celów biz­ne­so­wych dla każ­de­go poten­cjal­nie kupo­wa­ne­go modu­łu (pod­sys­te­mu) oraz wyma­ga­nia jako testy poka­zu­ją­ce reali­za­cję tych celów. Tych testów (wyma­gań) będzie raczej 30 niż 300, zaś ewen­tu­al­ne dedy­ko­wa­ne funk­cjo­nal­no­ści są pro­jek­to­wa­ne na ostat­ni moment” jeże­li oka­że się, że żaden ryn­ko­wy pro­dukt ich nie ofe­ru­je a nam na praw­dę są one potrzebne.

P.S.

Stale mnie nur­tu­je pyta­nie: dla­cze­go tak czę­sto są ogła­sza­ne prze­tar­gi na mega­pro­jek­ty i są skła­da­ne ofer­ty na mega wdro­że­nia, sko­ro to co napi­sa­łem nie sta­no­wi żad­ne­go odkrycia? 🙂

TOGAF or not TOGAF więc może Zachman

Badanie przy­dat­no­ści TOGAF/ArchiMate mam chy­ba za sobą (zapew­ne nie na mia­rę dok­to­ra­tu ale trosz­kę jed­nak tak, cho­ciaż…;)). Na stro­nie moje­go kole­gi: ArchitekturaKorporacyjna​.pl (pole­cam ana­li­ty­kom), w jed­nym z arty­ku­łów poja­wia się cie­ka­we stwierdzenie:

TOGAF wska­zu­je, że nie­wła­ści­we pod­czas mode­lo­wa­nia jest bez­po­śred­nie wią­za­nie pro­ce­su [biz­ne­so­we­go, jak sądzę] z apli­ka­cją go wspie­ra­ją­cą ? ele­men­tem pośred­nim powin­na być funk­cja ? czy­li: apli­ka­cja wspie­ra reali­za­cję funk­cji, a funk­cja obej­mu­je cały pro­ces lub jego frag­ment (w zależ­no­ści od pozio­mu dekom­po­zy­cji funk­cji biz­ne­so­wej). (Komentarze do TOGAF ? meta­mo­del zawar­to­ści (cz. II) | Architektura Korporacyjna).

i to jest coś co jako pierw­sze mnie zra­zi­ło w nota­cji ArchiMate: prze­rost poję­cio­wy (roz­drob­nie­nie albo jak kto woli nad­mier­na gra­da­cja). Umieszczenie dodat­ko­we­go poję­cia – funk­cja – pomię­dzy pro­ce­sem biz­ne­so­wym (pamię­ta­my, że samo­dziel­na czyn­ność to tak­że pro­ces) a narzę­dziem pra­cy jakim jest opro­gra­mo­wa­nie wyda­je się sztucz­ne. To trosz­kę jak umiesz­cze­nie pomię­dzy młot­kiem a pro­ce­sem wbi­ja­nia gwoź­dzia funk­cji wbi­ja­nie”, nie wiem jaką war­tość wno­si to do mode­lu, sko­ro mło­tek ma funk­cję (przy­pa­dek uży­cia) wbi­ja­nie” (pamię­taj­my, że opro­gra­mo­wa­nie to narzę­dzie pra­cy akto­ra, zasób).

Prowadzi to do nie­kom­pa­ty­bil­no­ści z sys­te­mem poję­cio­wym para­dyg­ma­tu obiek­to­we­go (MDA/OMG), na któ­ry ArchiMate się powo­łu­je, tym bar­dziej, że jed­nak MDA to stan­dard pro­ce­su obiek­to­we­go two­rze­nia opro­gra­mo­wa­nia więc po co z nim wal­czyć? Testowałem mode­le ArchiMate na ludziach” i oka­zy­wa­ło się, że dla wie­lu z nich tak­że są one nie­in­tu­icyj­ne. Trudno mi też wytłu­ma­czyć ten nad­miar poję­cio­wy: sko­ro w natu­rze” czyn­ność jest wspie­ra­na usłu­gą sys­te­mu” to po co pako­wać mię­dzy nie, mię­dzy tę wód­kę a zaką­skę” ;), poję­cie biz­ne­so­wej funk­cji opro­gra­mo­wa­nia sko­ro ono świad­czy jakąś usłu­gę, bo jest ona funk­cjo­nal­no­ścią tego oprogramowania.

Trzy warstwy modelowaniaAutorzy ArchiMate wska­zu­ją, że tam gdzie ArchiMate jest zbyt ogól­ne, nale­ży użyć odpo­wied­nio BPMN lub UML. Ale tu poja­wia się pro­blem: w UML usłu­ga opro­gra­mo­wa­nia to przy­pa­dek uży­cia powią­za­ny bez­po­śred­nio z akto­rem, któ­ry ma swój cel dzia­ła­nia (uży­cia sys­te­mu w trak­cie reali­za­cji pro­ce­su biz­ne­so­we­go). Czyli usłu­ga opro­gra­mo­wa­nia jest jed­nak poję­cio­wo bez­po­śred­nio zwią­za­na z czyn­no­ścią w pro­ce­sie, któ­rą wspie­ra (cel pra­cy akto­ra). To tyl­ko jed­na z nie­spój­no­ści. Jeżeli uznać, że pro­ces two­rze­nia opro­gra­mo­wa­nia to trzy fazy MDA opi­sa­ne przez OMG czy­li CIM, PIM i PSM (model biz­ne­so­wy, model logi­ki sys­te­mu, model jego imple­men­ta­cji), to nie­ste­ty TOGAF i ArchiMate są z nim nie­kom­pa­ty­bil­ne a TOGAF/ArchiMate nie daje nic w zamian, więc jest problem…

Z dru­giej stro­ny potrzeb­ne jest w każ­dym więk­szym pro­jek­cie upo­rząd­ko­wa­nie wie­dzy o orga­ni­za­cji z pomo­cą mode­li (któ­rych tu będzie wię­cej nią jeden) czy­li zro­zu­mie­nie jej zacho­wa­nia, wyma­ga to uję­cia tych mode­li w struk­tu­rę. Po co? By mieć mier­nik pozwa­la­ją­cy odpo­wie­dzieć na pyta­nie: Czy mamy już wszyst­kie potrzeb­ne mode­le, czy rozu­mie­my tę orga­ni­za­cję. Modele te to: pro­ce­sy biz­ne­so­we oraz obiek­to­we struk­tu­ry opro­gra­mo­wa­nia. Do tego mode­le poję­cio­we i regu­ły biz­ne­so­we. Wszystko to – nota­cje i ich mode­le poję­cio­we – jest bar­dzo dobrze opra­co­wa­ne w przez OMG. Czego bra­ku­je? Metamodelu cało­ści. Tu z pomo­cą przy­cho­dzi tak zwa­na [[Siatka Zachmana]]. Cóż to jest?

Siatka Zachmana (ang. Zachman Framework) ? sza­blon i spo­sób postę­po­wa­nia, któ­ry pozwa­la w spo­sób for­mal­ny i ści­śle ustruk­tu­ra­li­zo­wa­ny defi­nio­wać archi­tek­tu­rę sys­te­mów kor­po­ra­cyj­nych. Używa siat­ki bazu­jąc na sze­ściu pod­sta­wo­wych pyta­niach (Co, Jak, Gdzie, Kto, Kiedy, Dlaczego) zada­nych pię­ciu gru­pom użyt­kow­ni­ków (Planujący, Właściciel, Projektant, Twórca, Podwykonawca) aby przed­sta­wić holi­stycz­ny obraz przed­się­bior­stwa, któ­re jest mode­lo­wa­ne. (Siatka Zachmana ? Wikipedia, wol­na ency­klo­pe­dia).

Taka kom­plet­na siat­ka (matry­ca) wyglą­da tak:

Siatka Zachmana zakres analizy

Jest to peł­ny opis orga­ni­za­cji. Nie zawsze jest potrze­ba two­rze­nia cało­ści. Na eta­pie typo­wej ana­li­zy biz­ne­so­wej i ana­li­zy wyma­gań potrzeb­ne są eta­py CIM i PIM. W siat­ce Zachmana moż­na pomi­nąć zbęd­ne (tu nad­mia­ro­we, Zachman dopusz­cza czę­ścio­we struk­tu­ry) kolum­ny i wier­sze nadal zacho­wu­jąc kom­pa­ty­bil­ność z MDA:

Siatka Zachmana zakres analizy CIM PIM

Powyższe to nic inne­go jak matry­ca pozwa­la­ją­ca zbu­do­wać upo­rząd­ko­wa­ny model orga­ni­za­cji i umie­ścić w nim ist­nie­ją­ce, wspie­ra­ją­ca ją opro­gra­mo­wa­nie i (lub) opi­sać to, któ­re powin­no się w niej poja­wić czy­li wyma­ga­nia. Powyższe mapu­je się w 100% na model MDA: CIM i PIM. Nie trze­ba więc nicze­go zmie­niać a model poję­cio­wy jest spój­ny. Jeżeli ktoś korzy­sta z mode­lu MDA/OMG, bez pro­ble­mu może przy­po­rząd­ko­wać polom (prze­cię­cia wier­szy i kolumn) mode­le nota­cji BPMN, UML i BMM, a tak­że sys­te­my reguł biz­ne­so­wych i słow­nik pojęć dzie­dzi­no­wych. (powyż­sze zrzu­ty ekra­no­we narzę­dzia Agilian)

Z każ­dym kolej­nym pro­jek­tem skła­niam się ku tezie, że Architektura Korporacyjna, jako cało­ścio­we (lub jak kto woli: holi­stycz­ne) podej­ście do doku­men­to­wa­nia (mode­lo­wa­nia) orga­ni­za­cji, bliż­sza jest Siatce Zachmana niż TOGAF’owi, któ­ry w moich oczach jest po pro­tu prze­kom­bi­no­wa­ny i nie­kom­pa­ty­bil­ny z nota­cja­mi, od któ­rych raczej nie ma uciecz­ki (BPMN, UML, BMM a nawet struk­tu­ral­ne ERD i DFD).

Powyższy uprosz­czo­ny (wyłą­czo­ne nie­uży­wa­ne wier­sze i kolum­ny) kształt Siatki Zachmana, coraz czę­ściej słu­ży mi jako zakres pro­jek­tu ana­li­tycz­ne­go i korzeń jego struk­tu­ry. Poszukując mate­ria­łów na ten temat zna­la­złem opra­co­wa­nie opu­bli­ko­wa­ne na stro­nie Business Process Trends już w 2003 roku o wdzięcz­nym tytu­le: [[The Zachman Framework and the OMG’s Model Driven Architecture]]. Poniżej, na zakoń­cze­nie, dwa dia­gra­my zapo­ży­czo­ne z tego opracowania:

- mapo­wa­nie MDA na Siatkę Zachmana:

MDA2Zachman

oraz wska­za­nie, gdzie zasto­so­wać nota­cje UML:

UML2ZachmanPowyższy dia­gram war­to uzu­peł­nić uwa­gą, że zasto­so­wa­nie nota­cji BPMN w obsza­rze pro­ce­sów biz­ne­so­wych wyda­je się być obec­nie znacz­nie roz­sąd­niej­sze (w 2003 roku, nie była sto­so­wa­na), zaś w obsza­rze moty­wa­cji dosko­na­le spra­wu­je się BMM. OMG daje tak­że upo­rząd­ko­wa­ne sys­te­mu zapi­su reguł biz­ne­so­wych i słow­ni­ków pojęć.

TOGAF ma ambi­cje porów­ny­wa­nia się z Siatką Zachmana, jed­nak w moim odczu­ciu obsza­ro­we porów­na­nie – zgod­ność – to nie to samo z kom­pa­ty­bil­ność (tu już jej brak) z sys­te­ma­mi poję­cio­wy­mi (uzna­ny­mi za stan­dar­dy nota­cja­mi), bo to tu tkwi sens i sed­no pro­ble­mu. Jak na razie nie sądzę, by nota­cja ArchiMate – język wyra­zu TOGAF’a – wypar­ło doro­bek OMG, a nie­ste­ty nie jest w sta­nie go zastą­pić. Obecna postać Siatki Zachman v.3.0. to już ugrun­to­wa­na onto­lo­gia. (czy­sty pla­kat ZachmaFramework 3.0, widać na nim bar­dzo waż­ną rzecz: śla­do­wa­nie, mapo­wa­nie pomię­dzy modelami).

Siatka Zachmana w uży­ciu – pakiet Visual-Paradigm.

c.d.n.

Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie

eurekaZ poję­ciem ana­li­zy wyma­gań spo­ty­kam się regu­lar­nie, co chy­ba w moim przy­pad­ku nie jest zasko­cze­niem :). Jednak jest pewien niu­ans, któ­ry moż­na wychwy­cić ana­li­zu­jąc takie ana­li­zy wyma­gań, a tak­że słu­cha­jąc opo­wia­dań o przy­go­dach programistów.

Miałem nie­daw­no kolej­ny audyt doku­men­ta­cji wyma­gań opra­co­wa­nej samo­dziel­nie przez zama­wia­ją­ce­go. Była duża i trud­na w odbio­rze”, kil­ka osób z tej fir­my spi­sa­ło, każ­da dla swo­je­go dzia­łu i ze swo­jej per­spek­ty­wy, ocze­ki­wa­nia. Uporządkowali to tema­tycz­nie. Te kil­ka osób, plus ich pod­wład­ni, pra­co­wa­li nad tym trzy mie­sią­ce (mimo, że nie full time” to jed­nak suge­ru­je sobie same­mu osza­co­wać koszt tej pra­cy). Dokument w pier­wot­nej wer­sji prak­tycz­nie nie był przy­dat­ny. Drugim powo­dem napi­sa­nia tego arty­ku­ły była dys­ku­sja na pew­nym forum na temat kom­pe­ten­cji w IT, ale o tym na końcu.

Praktycznie zawsze spe­cy­fi­ka­cja wyma­gań wyko­na­na samo­dziel­nie przez zama­wia­ją­ce­go, to tak na praw­dę opis tego cze­go sobie życzy na bazie swo­ich dotych­cza­so­wych doświad­czeń. Regułą w takich przy­pad­kach w zasa­dzie jest to, że nowy sys­tem” to coś lep­sze­go od tego co mamy teraz”. Specyfikacja wyma­gań (jej treść) spro­wa­dza się do listy popra­wek i nowych żądań. Jeżeli wyma­ga­nia zosta­ły opra­co­wa­ne jako zapis wywia­dów lub ankiet przez tak zwa­ne­go ana­li­ty­ka” z zewnątrz (pra­cow­nik dostaw­cy opro­gra­mo­wa­nia, nie­za­leż­ny ana­li­tyk), efek­ty są prak­tycz­nie takie same (pomi­jam tu for­mę ich udokumentowania).

Zacytuje po raz kolej­ny meta­fo­rę z książ­ki Martina Fowlera:

Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram symu­lu­ją­cy grę w sno­oke­ra. Problem ten może zostać opi­sa­ny przy­pad­ka­mi uży­cia opi­su­ją­cy­mi powierz­chow­nie cechę: ?Gracz ude­rza bia­ła kulę, któ­ra prze­miesz­cza się z pew­ną pręd­ko­ścią, ta po okre­ślo­nym cza­sie ude­rza czer­wo­ną kulę pod okre­ślo­nym kątem, ude­rzo­na czer­wo­na kula prze­miesz­cza się na pew­na odle­głość w pew­nym kie­run­ku.? Możesz sfil­mo­wać set­ki tysię­cy takich ude­rzeń, zare­je­stro­wać para­me­try każ­de­go ude­rze­nia i jego skut­ki. Jednak tą meto­dą i tak nie stwo­rzysz nawet dość dobrej symulacji.

Jak nie trud­no się domy­śleć ana­li­za wyma­gań nie może trwać w nie­skoń­czo­ność, powsta­nie mało takich opi­sów sce­na­riu­szy czy­li opis moc­no nie­kom­plet­ny. Zapis wywia­dów, obser­wa­cje, ankie­ty i poprze­sta­nie na nich, nie mają pra­wa się spraw­dzić bo w skoń­czo­nym cza­sie na ana­li­zę zawsze będzie ich za mało a i tak będą cha­otycz­ne (będzie to tyl­ko część tego co może się wyda­rzyć i nie wia­do­mo, ile to pro­cent cało­ści bo nie zna­my wszystkich).

Przypadki uży­cia same w sobie, sta­no­wią bar­dzo mier­ne przy­bli­że­nie rze­czy­wi­sto­ści. Oddanie pro­gra­mu do użyt­ku, reali­zu­ją­ce­go tyl­ko ?kon­kret­ne sce­na­riu­sze? i to w spo­sób ?obmy­ślo­ny? przez pro­gra­mi­stę, któ­ry nie potra­fi grać w sno­oke­ra a tyl­ko sły­szał od gra­cza jak się to robi, naj­pew­niej skoń­czy się zaba­wą w kolej­ne ite­ra­cje, pro­to­ty­py itp. Taki pro­gram będzie coraz lep­szy ale nadal nie dotknie nawet reali­zmu sno­oke­ra (wię­cej o tym tu Czy wyma­ga­nia opi­su­ją tyl­ko to ?co? sys­tem ma robić?).

Fowler pisze:

Aby napi­sać na praw­dę dobrą grę, powi­nie­neś raczej zro­zu­mieć pra­wa rzą­dzą­ce ruchem kul, ich zależ­ność od siły i kie­run­ku ude­rze­nia, kie­run­ku itp. Zrozumienie tych praw pozwo­li Ci znacz­nie łatwiej napi­sać dobre oprogramowanie.

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

Jaka jest róż­ni­ca? Produktem ana­li­zy, czy­li zro­zu­mie­nia zja­wi­ska (pra­cy fir­my itp.) jest model jej logi­ki dzia­ła­nia (logi­ka biz­ne­so­wa), ten model – popraw­ny – pozwa­la prze­wi­dy­wać co nas cze­ka (testo­wa­ny jest na popraw­ność loso­wo wybra­ny­mi zda­rze­nia­mi w fir­mie). Ten model to model dzie­dzi­ny sys­te­mu (model logi­ki biz­ne­so­wej: spe­cy­fi­ka­cja reguł biz­ne­so­wych). Produktem wywia­dów jest nie­ste­ty wyłącz­nie opis skut­ków w reak­cji na bodź­ce (np. przy­pad­ki uży­cia) ale nadal nie­zro­zu­mia­łe jest to dla­cze­go aku­rat takie” skutki.

Wszystko to co nas ota­cza, samo w sobie jest natu­ral­nie pro­ste. Złożone są, nie poszcze­gól­ne rze­czy, a to, że jest ich wie­le i mają na sie­bie wza­jem­ny wpływ. Celem ana­li­zy jest ziden­ty­fi­ko­wa­nie w naszym oto­cze­niu tych pro­stych ele­men­tar­nych rze­czy i zro­zu­mie­nie ich wza­jem­ne­go na sie­bie wpły­wu. Zrozumienie to mani­fe­stu­je się w posta­ci umie­jęt­no­ści stwo­rze­nia mode­lu tych współ­ist­nie­ją­cych pro­stych rze­czy, zro­zu­mie­nia i opi­sa­nia ich cech i reguł wza­jem­ne­go oddzia­ły­wa­nia. Jeżeli tym ana­li­zo­wa­nym śro­do­wi­skiem jest orga­ni­za­cja, powsta­nie jej model, wie­dza o tym jak funk­cjo­nu­je. A gdzie tu jest miej­sce na opro­gra­mo­wa­nie? By powsta­ło, nale­ży stwo­rzyć tak­że i jego model, by zro­zu­mieć i opi­sać to cze­go potrze­buj­my. Pamiętajmy, że jed­na z naj­trud­niej­szych gier na świe­cie ? sza­chy ? to tyl­ko kil­ka­na­ście figur i pro­ste regu­ły ich prze­miesz­cza­nia. Nawet naj­więk­sza orga­ni­za­cja to tyl­ko skoń­czo­na licz­ba ról i reguł ich postę­po­wa­nia. Należy je tyl­ko odkryć. (żr. Jarosław Żeliński, refe­rat na kon­fe­ren­cji: Firma IT-Consulting Jarosław Żeliński – ana­li­tyk biz­ne­so­wy).

Nie kry­ty­ku­je idei sto­so­wa­nia przy­pad­ków uży­cia, sam je sto­su­ję. One jed­nak są kon­kret­ny­mi, pla­no­wa­ny­mi przy­pad­ka­mi uży­cia opro­gra­mo­wa­nia, to mini­mal­ny zestaw opcji w menu – wyma­ga­ne teraz” usłu­gi sys­te­mu. To nie ma jed­nak nic wspól­ne­go z wewnętrz­ną budo­wą opro­gra­mo­wa­nia, ta powin­na mode­lo­wać zasta­ną rzeczywistość.

Istnieje coś takie­go jak zasa­da SOLID pro­jek­to­wa­nia opro­gra­mo­wa­nia (jed­na z klu­czo­wych cech dobrych pro­jek­tów opro­gra­mo­wa­nia). Cóż to jest SOLID? To roz­wi­nię­cie od ang. Single respon­si­bi­li­ty, Open-clo­sed, Liskov sub­sti­tu­tion, Inter­fa­ce segre­ga­tion and Depen­den­cy inver­sion (wię­cej na stro­nie SOLID (object-orien­ted design) – Wikipedia, the free encyc­lo­pe­dia).

Dzisiaj tyl­ko o skut­kach zanie­dba­nia jed­nej, klu­czo­wej chy­ba wła­sno­ści, któ­ra doty­czy całej apli­ka­cji: Open-Close, któ­ra ozna­cza: apli­ka­cja powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­bu­do­wę.  Dla wie­lu na począt­ku ta zasa­da brzmi wręcz kurio­zal­nie ale ona jak naj­bar­dziej jest moż­li­wa do reali­za­cji. Proszę zwró­cić uwa­gę, że takie wła­snie są dobrze zarzą­dza­ne fir­my, nie ma w nich rewo­lu­cji orga­ni­za­cyj­nej co roku, one się roz­wi­ja­ją a nie zmieniają.

Oprogramowanie, jeże­li w wyni­ku ana­li­zy wyma­gań opra­co­wa­no nie tyl­ko raport z wywia­dów ale tak­że model logi­ki dzia­ła­nia, też speł­ni te zasa­dę. Czym gro­zi jej nie­speł­nie­nie w sto­sun­ku do opro­gra­mo­wa­nia? A tym, do cze­go przy­znał się jeden z pro­gra­mi­stów pod­czas pew­nej dys­ku­sji na forum:

kil­ka razy doświad­czy­łem sytu­acji, że aby speł­nić nowe pro­ste wyma­ga­nie trze­ba było się namę­czyć zarów­no z mode­lem danych jak i apli­ka­cją, Oczywiście moż­na w takiej sytu­acji zarzu­cić, że sys­tem był źle zapro­jek­to­wa­ny, nie­ska­lo­wal­ny, nie prze­strze­gał SOLIDów, nie korzy­stał z wzor­ców itd ale to już jest inna bajka.

Na co ja odpo­wie­dzia­łem: nie, to jest wła­śnie ta baj­ka o nazwie ana­li­za wyma­gań i pro­jek­to­wa­nie, któ­re powin­ny być zro­zu­mie­niem a nie tyl­ko ste­no­gra­mem. Wtedy nowe funk­cjo­nal­no­ści opro­gra­mo­wa­nia moż­na doda­wać bez potrze­by prze­bu­do­wy jego wewnętrz­nej struk­tu­ry. Nie raz jest z powo­du tych kosz­tów po pro­tu nie­moż­li­wy jest roz­wój sys­te­mu. Oceńcie teraz Państwo sami, Ci któ­rzy tego doświad­czy­li, skut­ki wdro­że­nia np. sys­te­mu ERP z kasto­mi­za­cją.… nie­ste­ty ogrom­na więk­szość tego opro­gra­mo­wa­nia nie speł­nia zasa­dy SOLID. Dlaczego? Bo model rela­cyj­ny baz danych, jeże­li obej­mu­je wszyst­kie dane sys­te­mu, nie­ste­ty nie speł­nia tej zasa­dy z zało­że­nia. A dostaw­cy tych sys­te­mów wręcz cie­szą się z tego rekla­mu­jąc się: nasz sys­tem jest w peł­ni zin­te­gro­wa­ny poprzez pra­cę na wspól­nej bazie danych”.… Jak to prze­czy­tasz, nie kupuj tego…

Przetarg czyli wycena projektu…

teczki, akta, papiery

O prze­tar­gach napi­sa­no tak wie­le kry­tycz­nych tek­stów, więc po co ten? Nie będę się tu pastwił nad nimi. Zastanawia mnie co inne­go, i tu mała krytyka…

W pra­sie poja­wi­ły się donie­sie­nia o roz­strzy­ga­nym prze­tar­gu ogło­szo­nym przez [[ARiMR]]:

Asseco Poland za swo­je pra­ce zapro­po­no­wa­ło 40,65 mln zł, a Sygnity 43,98 mln zł. W prze­tar­gu star­to­wa­ły też: kon­sor­cjum ze spół­ką zależ­ną Asseco – ZETO Łódź (29,36 mln zł) i kon­sor­cjum z Infovide-Matrix (31,75 mln zł). Wybrana poprzed­nio [[ofer­ta kon­sor­cjum IT Works i Almaviva]] opie­wa­ła na 9,92 mln zł. Przetarg reali­zo­wa­ny był według pro­ce­du­ry ogra­ni­czo­nej przy­spie­szo­nej. Kryterium oce­ny ofert w tym postę­po­wa­niu była cena. (Oferta Comarchu naj­ko­rzyst­niej­sza w prze­tar­gu ARiMR. wnp​.pl | Informatyka. Informatyka dla prze­my­słu.).

Co mnie zasta­na­wia? Przede wszyst­kim to, że pro­fe­sjo­nal­ne” fir­my z ogrom­nym (jak twier­dzą na swo­ich stro­nach) doświad­cze­niem, pre­zen­tu­ją ofer­ty opra­co­wa­ne na bazie tej samej doku­men­ta­cji (w koń­cu to prze­targ), a roz­rzut cen tych ofert jest czterokrotny!!!

Nie może to być (tak sądzę) kwe­stią zakre­su pro­jek­tu, bo ten jest opi­sa­ny w SIWZ (Specyfikacja Istotnych Warunków Zamówienia, ta zawie­ra Opis Przedmiotu Zamówienia). Czy na pew­no? Wstępnie wyda­je mi się, że są dwie moż­li­we przy­czy­ny takie­go roz­rzu­tu: sła­by OPZ albo róż­ni­ce w spo­so­bie i meto­dach pra­cy ofe­ren­tów, tu wyce­ny i metod wytwa­rza­nia. Popatrzmy na kry­te­ria oce­ny (źr. str. WWW AMRiR):

kry­te­ria udzie­le­nia zamó­wie­nia: Cena rocz­ne­go utrzy­ma­nia ? 55%. Cena 1 Punktu Funkcyjnego – 35%. Gwarancja ? 10% gwa­ran­cja na opro­gra­mo­wa­nie, funk­cjo­nu­ją­ce w dniu zakoń­cze­nia obo­wią­zy­wa­nia umo­wy, roz­po­czy­na­ją­ca się od dnia zakoń­cze­nia umo­wy. Każdy mie­siąc trwa­nia gwa­ran­cji + 2,5 pkt., mak­sy­mal­nie 10 pkt.

Jednym ze skład­ni­ków ceny jest tak zwa­ny punkt funk­cyj­ny”. Cóż to jest? To jed­na z popu­lar­niej­szych metod wyce­ny. Jak to dzia­ła? WIKI:

Podstawowym zało­że­niem meto­dy punk­tów funk­cyj­nych jest podzie­le­nie opro­gra­mo­wa­nia na pięć składowych.

  1. Zewnętrzne typy wej­ścia to meto­dy doko­ny­wa­nia zmian w wewnętrz­nych danych systemu.
  2. Zewnętrzne typy wyj­ścia to meto­dy repre­zen­ta­cji danych prze­cho­wy­wa­nych przez sys­tem. Przykładem są wydru­ki kom­pu­te­ro­we. Dane wyświe­tla­ne na ekra­nie nie nale­żą do tej kate­go­rii, są kwa­li­fi­ko­wa­ne jako opi­sa­ne poni­żej zewnętrz­ne typy zapytań.
  3. Logiczne wewnętrz­ne typy pli­ków to pli­ki uży­wa­ne wewnętrz­nie przez sys­tem. We współ­cze­snej infor­ma­ty­ce poję­cie pli­ku zmie­ni­ło swo­je zna­cze­nie. Składową tą może­my inter­pre­to­wać jako zbiór danych opi­su­ją­cych obiek­ty dane­go typu, na przy­kład tabe­lę w rela­cyj­nej bazie danych.
  4. Zewnętrzne typy inter­fej­sów pli­ków to meto­dy wymia­ny danych mię­dzy inny­mi sys­te­ma­mi infor­ma­tycz­ny­mi. Przykładem może być inter­fejs umoż­li­wia­ją­cy pobie­ra­nie danych z apli­ka­cji inter­ne­to­wej w for­ma­cie JSON lub pli­ki współ­dzie­lo­ne mię­dzy róż­ny­mi aplikacjami.
  5. Zewnętrzne typy zapy­tań to meto­dy odczy­tu danych z sys­te­mu nie powo­du­ją­ce ich mody­fi­ka­cji. Przykładem jest zapy­ta­nie SELECT z języ­ka SQL.

Wady meto­dy wska­za­ne w jej opi­sie w WIKI:

  • Mimo że meto­da jest naj­bar­dziej dopra­co­wa­ną i naj­po­pu­lar­niej­szą meto­dą sza­co­wa­nia war­to­ści funk­cji oce­nia­ne­go pro­gra­mu, to nie pozo­sta­je ona bez wad. Jedną z nich, wska­za­ną już przez Albrechta, jest subiek­tyw­ność war­to­ścio­wa­nia zło­żo­no­ści typu jako niskiej, śred­niej lub dużej. Istotność tej wady obec­nie jest niwe­lo­wa­na opra­co­wa­ną przez IFPUG meto­dy­ką oce­ny zło­żo­no­ści (file type complexity).
  • Kolejnym pro­ble­mem jest cza­so­chłon­ność (koszt) pro­ce­su wyli­cza­nia punk­tów funk­cyj­nych, gdyż z powo­du nie­zna­nej dokład­no­ści takich wyli­czeń nie jest sto­so­wa­na auto­ma­ty­za­cja. tego pro­ce­su , ponie­waż nie­zna­na jest w takim przy­pad­ku – nie wia­do­mo czy jest duża czy mała.
  • Innym man­ka­men­tem jest to, że wyni­ki meto­dy w przy­pad­ku małych sys­te­mów mogą być mało dokładne.
  • Metoda punk­tów funk­cyj­nych nie bie­rze rów­nież pod uwa­gę zło­żo­no­ści imple­men­ta­cji algo­ryt­mów dzia­ła­ją­cych wewnątrz systemu.

(Punkt funk­cyj­ny ? Wikipedia, wol­na ency­klo­pe­dia.)

Po pierw­sze meto­da powsta­ła ponad 30 lat temu, gdy stan­dar­do­wą meto­dy­ką two­rze­nia opro­gra­mo­wa­nia były meto­dy struk­tu­ral­ne (bazu­ją na odse­pa­ro­wa­nej liście funk­cji prze­twa­rza­ją­cych dane prze­cho­wy­wa­ne w odręb­nej bazie danych w mode­lu rela­cyj­nym stad przy­kład z SELECT’em w języ­ku SQL). Metoda, choć archa­icz­na, jest nadal roz­wi­ja­na i dość powszech­nie sto­so­wa­na. Dlaczego? Moim zda­niem dla­te­go, że bazu­je na tak zwa­nej per­spek­ty­wie użyt­kow­ni­ka”: Granice [zakre­su ana­li­zy] powi­nien okre­ślać użyt­kow­nik w opar­ciu o swój punkt widze­nia i zapo­trze­bo­wa­nie. Ograniczenia tech­no­lo­gicz­ne nie powin­ny być bra­ne pod uwa­gę pod­czas okre­śla­nia gra­nic mię­dzy współ­pra­cu­ją­cy­mi sys­te­ma­mi. Należy kie­ro­wać się przy tym ich funk­cjo­nal­no­ścią. (WIKI). Jest to łatwa i pro­sta meto­da, nie wyma­ga zbyt dużych kom­pe­ten­cji (a pamię­taj­my, że duże fir­my czę­sto cechu­je dość duża rota­cja pra­cow­ni­ków co nie sprzy­ja gro­ma­dze­niu kompetencji).

Powszechnie przy­ję­tą prak­ty­ką jest wyce­na wyko­na­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia na bazie opi­su wyma­gań naj­czę­ściej w posta­ci wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych”. Jednak tak opi­sa­ne wyma­ga­nia to jedy­nie opis tego jaki efekt chce osią­gnąć zama­wia­ją­cy, nic nie mówią o tym jak” on zosta­nie osią­gnię­ty. Metod i narzę­dzi wytwa­rza­nia opro­gra­mo­wa­nia jest wie­le, kom­pe­ten­cje wyko­naw­ców tak­że bar­dzo róż­ne. W efek­cie, moim zda­niem, oce­na ofert na bazie takich spe­cy­fi­ka­cji to lote­ria. (moim zda­niem meto­dy wyce­ny opar­te na przy­pad­kach uży­cia i obiek­to­wych wzor­cach pro­jek­to­wych ich imple­men­ta­cji są znacz­nie bar­dziej wia­ry­god­ne, opis przy innej okazji).

Drugi ele­ment to oce­na ofe­ren­tów. Bardzo czę­sto zama­wia­ją­cy narzu­ca ogrom­ne wyma­ga­nia finan­so­we na dostaw­ców: wyso­kie wadium, wyso­kie wyma­ga­nia na obro­ty rocz­ne itp. Do tego lata doświad­czeń itp. Popatrzmy na pro­fe­sjo­na­lizm inży­nie­rii i umie­jęt­no­ści o podob­nym cha­rak­te­rze: co świad­czy o mecha­ni­ku samo­cho­do­wym? To ile lat napra­wia samo­cho­dy czy to jakie i jaki­mi meto­da­mi? Czy to, że zespół pro­gra­mi­stów to ludzie od 15 lat piszą­cy opro­gra­mo­wa­nie w Pascalu, pozwa­la uznać ich za bar­dzo dobrych spe­cja­li­stów? W czym?

Dzisiaj na ryn­ku inży­nie­rii opro­gra­mo­wa­nia kró­lu­ją meto­dy i narzę­dzia obiek­to­we (co by to nie mia­ło zna­czyć) a nie struk­tu­ral­ne, uzna­ne daw­no za nie­efek­tyw­ne w two­rze­niu opro­gra­mo­wa­nia o cha­rak­te­rze biz­ne­so­wym (o innym się nie wypo­wia­dam ;)). Metody obiek­to­we są efek­tyw­niej­sze zarów­no na eta­pie ana­li­zy i pro­jek­to­wa­nia jak i na eta­pie imple­men­ta­cji, ale wyma­ga­ją zupeł­nie nowej wie­dzy w sto­sun­ku do metod struk­tu­ral­nych (nie­ste­ty nasze uczel­nie uczą głów­nie metod strukturalnych).

Czy powyż­szy roz­rzut cen to efekt róż­nic w tech­no­lo­gii sto­so­wa­nej przez ofe­ren­tów czy ich kom­pe­ten­cji? Osobiście sta­wiam głow­nie na nie­sku­tecz­ność meto­dy punk­tów funk­cyj­nych i wła­snie sła­be kompetencje.

Trudno o inne wnio­ski. Za mało danych zawie­ra­ją infor­ma­cje z roz­strzy­ga­nych prze­tar­gów, a nie­ste­ty ofer­ty nie są publi­ko­wa­ne (nie rozu­miem dla­cze­go i nie ja jeden.…). Argument, że ofer­ta jest pouf­na” do mnie nie prze­ma­wia, bo Urzędy nie mają chro­nio­ne­go know-how a więc logi­ka nowe­go sys­te­mu nie powin­na być tajem­ni­cą, cena jest jaw­na z urzę­du, pozo­sta­je więc (moja) nie­wie­dza na temat tech­no­lo­gii i metod jakie zasto­su­je dostaw­ca (to co pre­zen­tu­je na swo­jej stro­nie WWW rzad­ko kie­dy jest praw­dą w pro­jek­tach, z tego co obserwuję).

Tak więc sko­ro ofer­ty zawie­ra­ją taki roz­rzut cen, to moim zda­niem sys­tem” jest zły, zarów­no oce­ny ofert (cena jako 100%) jak i two­rze­nia OPZ, któ­re z regu­ły są listą poboż­nych” życzeń pra­cow­ni­ków zama­wia­ją­ce­go. Bez zna­cze­nia jest to, czy tę listę opra­co­wał sam zama­wia­ją­cy czy zatrud­nio­ny ana­li­tyk reali­zu­ją­cy sesje warsz­ta­to­we, burze mózgów czy ankie­ty. Analiza punk­tów funk­cyj­nych, jako kon­ty­nu­acja tak opra­co­wa­nej listy wyma­gań, tym bar­dziej nie wró­ży nic sen­sow­ne­go, bo jak wspo­mnia­łem nie­daw­no Analityk (tak wewnętrz­ny jak i zewnętrz­ny) to nie dyk­ta­fon.

Tak więc mamy kolej­ny przy­kład, że sys­tem prze­tar­gów nie dzia­ła” jak powi­nien, nicze­go nie gwa­ran­tu­je poza zawy­ża­niem cen (utrzy­ma­nie dużej kor­po­ra­cji i jej akcjo­na­riu­szy kosz­tu­je, a wiel­kość fir­my nie gwa­ran­tu­je nicze­go w kwe­stii jako­ści prac pro­gra­mi­stycz­nych co poka­zu­ją kolej­ne afe­ry i upa­dłe pro­jek­ty nie tyl­ko w naszym kra­ju np. ostat­nio Fiasko bry­tyj­skiej kom­pu­te­ry­za­cji i lek­cja dla Polski), obec­nie PZP słu­ży raczej eli­mi­no­wa­niu mniej­szych i nie raz znacz­nie lep­szych i tań­szych firm.

A naj­bar­dziej mnie zaska­ku­je to, że ASSECO zło­ży­ło ofer­tę o 25% droż­szą niż ich spół­ka zależ­na ZETO Łódź. Czyżby ase­ku­ra­cja by pie­nią­dze nie uciekły?.

Analityk to nie dyktafon

Dzisiaj żad­nych tech­nicz­nych mądrości ;).

Poprzedni arty­kuł zaczy­nał się od słów:

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łęd­ne­go. (Gdzie się reali­zu­ją wyma­ga­nia).

Uważam, że rolą ana­li­ty­ka nie jest ZBIERANIE WYMAGAŃ, bo wyma­ga­nia powi­nien mieć spon­sor pro­jek­tu (i nie powin­ny to być np. listy roz­wi­ja­ne w menu)! Rolą ana­li­ty­ka jest ana­li­za! Analiza pole­ga na ana­li­zie (:)), zro­zu­mie­niu ana­li­zo­wa­ne­go przed­mio­tu (fir­ma, zja­wi­sko na ryn­ku, inte­rak­cje spo­łecz­ne – testo­wa­nie pro­jek­tu nowe­go pra­wa, itp.).

Tak więc pro­duk­tem pra­cy ana­li­ty­ka jest przede wszyst­kim model tego co zosta­ło zana­li­zo­wa­ne. Celem jest zrozumienie.

Jak to się ma do opro­gra­mo­wa­nia? Ma się bar­dzo, bo nale­ży zamie­nić (a raczej olać) sło­wa przy­szłe­go use­ra chce­my tak, bo zawsze tak robi­li­śmy”, na obiek­tyw­ny i logicz­ny – zro­zu­mia­ły – opis tego co jest robione.

A gdzie wyma­ga­nia? No wyma­ga­nie to np. pro­gram ma wspie­rać wysta­wia­nie fak­tur VAT” ale nie pytam o to use­ra”, bo po pierw­sze to nie user” o tym decy­du­je. Po dru­gie w poszu­ki­wa­niu szcze­gó­łów drą­żę usta­wę i ewen­tu­al­nie kon­sul­tu­je się z bie­głym rewi­den­tem, use­ra” w ogó­le nie pytam o to jak liczyć poda­tek VAT i jak obsłu­żyć maga­zyn. Dlaczego? Z bar­dzo pro­ste­go powo­du: mało kie­dy user” czy­ta prze­pi­sy, wie­dzę o fak­tu­ro­wa­niu posia­da w więk­szo­ści przy­pad­ków z krót­kich szko­leń lub prze­lot­nych opo­wie­ści poprzed­ni­ka na swo­im sta­no­wi­sku (wie­my jak są prze­ka­zy­wa­ne obo­wiąz­ki w fir­mach). Znam tak wie­le przy­pad­ków błęd­ne­go two­rze­nia doku­men­tów przez wie­lo­let­nich pra­cow­ni­ków z ogrom­nym doświad­cze­niem”, że oduczy­łem się trak­to­wa­nia ich jako głów­ne­go źró­dła wyma­gań. Koronnym przy­kła­dem była nie tak daw­no dla mnie pew­na Pani w pew­nym urzę­dzie, tak zwa­ny star­szy spe­cja­li­sta, wie­lo­let­ni pra­cow­nik sekre­ta­ria­tu, któ­ra zarze­ka­ła się, że moż­na pod­pi­sy­wać doku­men­ty urzę­do­we prze­ter­mi­no­wa­nym pod­pi­sem elek­tro­nicz­nym, i że wystar­czy zazna­czyć, kie­dy ten pod­pis stra­cił waż­ność. Gdybym na bazie wie­dzy” pozy­ska­nej od tego use­ra” przy­go­to­wał spe­cy­fi­ka­cje wyma­gań, to… tra­ge­dia. Czy uspra­wie­dli­wia kogo­kol­wiek to, że user tak chciał”? W moich oczach abso­lut­nie nie… W moich oczach spon­sor pro­jek­tu ocze­ku­je ode mnie ana­li­zy a nie ste­no­gra­mów z rozmów!

Jednym z innych przy­kła­dów tego jak user sta­wia wyma­ga­nia”, są (pro­szę wyba­czyć sło­wo) kre­tyń­skie sys­te­my dopusz­cza­ją­ce w maga­zy­nach ujem­ne sta­ny maga­zy­no­we. To jest nie­zgod­ne z pra­wem! Da się sprze­da­wać legal­nie, nawet towar w dro­dze, trze­ba jed­nak zro­zu­mieć zja­wi­sko, prze­pi­sy i zapro­po­no­wać legal­ne roz­wią­za­nie (da się).

W kwe­stii szcze­gó­ło­wo­ści opi­su, bo ta budzi wie­le emo­cji. Powiem prze­wrot­nie tak: szcze­gó­ły są potrzeb­ne tyl­ko tam, gdzie są potrzeb­ne szcze­gó­ły. Czyli gdzie? Tam gdzie zacho­dzi ryzy­ko, że brak tych szcze­gó­łów dopro­wa­dzi do nie­przy­dat­no­ści sys­te­mu ale tyl­ko tam. Nie zapo­mi­naj­my, że gro­ma­dze­nie i prze­twa­rza­nie tych szcze­gó­łów to koszt. Kosztem jest tak­że, usu­wa­nie kon­se­kwen­cji złe­go wybo­ru z powo­du bra­ku pew­nych szcze­gó­łów. Nie ma na to pyta­nie pro­stej odpo­wie­dzi, bo każ­dy pro­jekt jest inny. Inne są wyma­ga­nia biz­ne­so­we, inne ryzy­ka biz­ne­so­we, inne uwa­run­ko­wa­nia wewnętrz­ne (np. już posia­da­ne systemy).

Spotykam się czę­sto na kon­fe­ren­cjach i szko­le­niach z pyta­nia­mi o regu­ły two­rze­nia dobrej spe­cy­fi­ka­cji wyma­gań”. Obawiam się, że nie nie ist­nie­je taka. Podobnie jak nie ist­nie­je regu­ła two­rze­nia dobrych zdjęć, co nie zmie­nia fak­tu, że spo­koj­nie moż­na powie­dzieć jaką mini­mal­ną wie­dzę i sprzęt trze­ba posia­dać, by robić zdję­cia na wyso­kim poziomie.

Tak więc

Powszechnie uwa­ża się, że ana­li­za wyma­gań na opro­gra­mo­wa­nie to pro­sty, ale pra­co­chłon­ny pro­ces pro­wa­dze­nia wywia­dów i skrzęt­ne­go zapi­sy­wa­nia tego, cze­go ocze­ku­je przy­szły użyt­kow­nik. Nic bar­dziej błęd­ne­go ? jest to naj­gor­szy spo­sób. (A na grzy­ba nam Pan Analityk?).

więc co z tymi wyma­ga­nia­mi? Przypomnę definicję:

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

Tak więc wyma­ga­nia na opro­gra­mo­wa­nie to mini­mal­na licz­ba (spe­cy­fi­ka­cja) warun­ków, któ­rych speł­nie­nie potwier­dza przy­dat­ność tego opro­gra­mo­wa­nia do okre­ślo­ne­go celu. Oznacza to, że przede wszyst­kim nale­ży okre­ślić cele! Jeżeli nie znaj­dzie­my takie­go opro­gra­mo­wa­nia na ryn­ku, wte­dy nale­ży wyko­nać stu­dium wyko­ny­wal­no­ści pro­jek­tu dostar­cze­nia dedy­ko­wa­ne­go oprogramowania.

Jak okre­ślać cele? Przypadek uży­cia, wyma­ga­na usłu­ga sys­te­mu, to nic inne­go jak wła­śnie cel. Celem jest moż­li­wość wysta­wia­nia doku­men­tów XXX, celem jest gene­ro­wa­nie rapor­tów kon­tro­l­nych wyko­na­nia pla­nu pro­duk­cji i obcią­że­nia maszyn. Jeżeli sys­tem jest duży, celem (jed­nost­ka opi­su wyma­gań) jest wspar­cie pro­ce­su obsłu­gi zamó­wień (i opis tego pro­ce­su jako załącz­nik). Ale nie jest dobrym celem zaku­pu opro­gra­mo­wa­nia: roz­wi­ja­na lista kon­tra­hen­tów na ekra­nie two­rze­nia nowej fak­tu­ry” czy moż­li­wość wpro­wa­dze­nia nazwy uli­cy, kodu i nazwy mia­sta w kar­to­te­ce klienta”.

Jak mam nadzie­ję widać, nie bar­dzo ma sens pory­wa­nie się na zakup wiel­kie­go pakie­tu zin­te­gro­wa­ne­go”, bo jak tu opra­co­wać w roz­sąd­nym cza­sie i kosz­cie, spe­cy­fi­ka­cję wyma­gań? Opracować listę celów wszyst­kich komó­rek orga­ni­za­cyj­nych?? Jak zagwa­ran­to­wać jej sta­łość (zakres pro­jek­tu), jeże­li taki pro­jekt trwa np. pięć lat? Życzę powodzenia…

P.S.

Pewne cele są reali­zo­wa­ne kon­kret­ną meto­dą, wte­dy trze­ba dokład­nie udo­ku­men­to­wać tę meto­dę. Np. meto­dę nali­cza­nia wyna­gro­dzeń nale­ży dokład­nie udo­ku­men­to­wać, ale tyl­ko pod warun­kiem, że celem jest ta meto­da, a nie sam fakt wypła­ty jakichś” wyna­gro­dzeń. Jeżeli meto­dy się zmie­nia­ją, wyma­ga­niem nie może być kon­kret­na meto­da, a narzę­dzie (mecha­nizm dostęp­ny w opro­gra­mo­wa­niu) pozwa­la­ją­ce na defi­nio­wa­nie tych metod. Tu jed­nak nale­ży udo­ku­men­to­wać regu­ły two­rze­nia tych metod… bo gorą­ca odra­dzam wyma­ga­nie w posta­ci sys­tem powi­nien pozwa­lać na defi­nio­wa­nie róż­nych metod nali­cze­nia wyna­gro­dze­nia”, bo to po pro­stu nic nie znaczy.

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Nowy paradygmat systemowy

Na stro­nach www​.moder​na​na​lyst​.com poja­wił się kolej­ny cie­ka­wy arty­kuł, klu­czo­we tezy to:

The two major are­as for chan­ge dri­ving the new IS shift are the desi­re or need to:

(1) mana­ge busi­ness pro­cess and busi­ness rules as sepa­ra­te but clo­se­ly rela­ted and con­nec­ted reso­ur­ces and

(2) decom­po­se softwa­re or pro­gram­ming code into reu­sa­ble modu­les, cal­led servi­ces, mana­ged by a servi­ce orien­ted archi­tec­tu­re (SOA) infra­struc­tu­re. The SOA infra­struc­tu­re mana­ges and media­tes servi­ces used in a busi­ness process.

(A New Information Systems Paradigm: What does a Business Analyst Needs to Know?).

To kolej­ne źró­dło, któ­re publi­ku­je prze­po­wied­nię” mówią­cą, że klu­czo­wy wpływ na roz­wój i pro­jek­to­wa­nie sys­te­mów infor­ma­tycz­nych będą mia­ły dwie klu­czo­we kom­pe­ten­cje i ana­li­ty­ków i pro­jek­tan­tów: zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi i regu­ła­mi biz­ne­so­wy­mi jako odręb­ny­mi, powią­za­ny­mi obsza­ra­mi, opi­su­ją­cy­mi orga­ni­za­cje oraz umie­jęt­ność dekom­po­zy­cji opro­gra­mo­wa­nia na samo­dziel­ne odręb­ne modu­ły-usłu­gi, któ­rych moż­na nie­za­leż­nie uży­wać np. w archi­tek­tu­rze SOA. Architektura SOA daje moż­li­wość nie­za­leż­ne­go przy­po­rząd­ko­wa­nia potrzeb­nych usług do kon­kret­nych pro­ce­sów biznesowych.

W 2007 roku pisa­łem, że prze­wi­du­ję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych. Dotychczasowa ich zale­ta czy­li peł­na inte­gra­cja prze­sta­je być zale­tą a sta­je się gar­bem. System zin­te­gro­wa­ny moż­na już ?skle­ić? ze spe­cja­li­zo­wa­nych apli­ka­cji, kom­po­nen­tów. Technologia obiek­to­wa bar­dzo ten pro­ces uła­twi­ła. Drugim powo­dem prze­wi­dy­wa­ne­go odej­ścia od tej idei są ogrom­ne kło­po­ty z oce­ną ren­tow­no­ści wdro­że­nia sys­te­mu ERP. Nie raz jest to po pro­stu wręcz nie­moż­li­we z powo­du bra­ku moż­li­wo­ści oce­ny jakim kosz­tem wspie­ra­my poje­dyn­czy pro­ces biz­ne­so­wy bo trud­no z jed­ne­go ogrom­ne­go sys­te­mu wykro­ić koszt wspar­cia poje­dyn­cze­go pro­ce­su. (Czy to już nad­cho­dzą­cy koniec zin­te­gro­wa­nych ERP?).

W roku 2011, rok temu moż­na było zauwa­żyć, że rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. Dobry sys­tem ERP to śro­do­wi­sko pro­gra­mi­stycz­ne (tak zwa­ny fra­me­work, szkie­let). Systemy, nawę je ?zapóź­nio­ne?, nadal wyma­ga­ją inge­ren­cji w ich kod by cokol­wiek osią­gnąć. Kompromisem jest sytu­acja, w któ­rej sys­tem ERP ma boga­ty inter­fejs (tak zwa­ne API, Application Programming Interface) pozwa­la­ją­cy na inte­gra­cję dedy­ko­wa­nych pod­sys­te­mów lub wła­śnie zewnętrz­nych kom­po­nen­tów czy­li korzy­sta­nia z moż­li­wo­ści jakie daje Cloud Computing). Przyszłość to kom­po­nen­ty? (Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP).

W ubie­głym roku na kon­fe­ren­cji SOA Executive Forum mia­łem refe­rat Jak rozu­mia­ne SOA odej­dzie do lamu­sa? Co nastą­pi po SOA?. Poruszyłem kil­ka spraw:

  1. SOA jako Service Oriented Architectute, czym było jako technologia?
  2. SOA jako Service Oriented Analysis a cóż to takiego?
  3. SOA jako nowo­cze­sna archi­tek­tu­ra sys­te­mów wspo­ma­ga­ją­cych zarządzanie
  4. Nowe cza­sy: archi­tek­tu­ra opar­ta na kom­po­nen­tach ryn­ko­wych czy­li SaaS, Clod Computing i inne

Duże zain­te­re­so­wa­nie wzbu­dzi­ło wte­dy roz­wi­nię­cie skró­tu: [[Service Oriented Analysis]]. Otóż ana­li­za pro­ce­sów biz­ne­so­wych i nastę­pu­ją­ca po niej ana­li­za wyma­gań, a być może dalej obiek­to­we pro­jek­to­wa­nie, pro­wa­dzi wła­śnie do orien­ta­cji na usłu­gi”. Przypadek uży­cia w UML (i jako wyma­ga­nie w obiek­to­wym para­dyg­ma­cie) to nic inne­go jak usłu­ga sys­te­mu. Nic nie stoi na prze­szko­dzie, by je – te usłu­gi – imple­men­to­wać oddziel­nie i nie­za­leż­nie. Otrzymamy wte­dy zna­ne od lat COTS. Powyższy dia­gram jasno poka­zu­je, że sys­tem” wspo­ma­ga­ją­cy zarzą­dza­nie to pakiet usług wspo­ma­ga­ją­cych kon­kret­ne pro­ce­sy biz­ne­so­we i nie koniecz­nie będą­cy jed­nym zin­te­gro­wa­nym pakie­tem opro­gra­mo­wa­nia ERP II.

Podejście takie jest wygod­ne gdyż pozwa­la pro­jek­to­wać i wdra­żać nawet bar­dzo zło­żo­ne sys­te­my meto­dą kolej­nych kro­ków-kom­po­nen­tów, spo­koj­nie moż­na je nazwać eta­pa­mi a całość, zwin­nym pro­jek­tem. Jednak z dru­giej stro­ny ta zwin­ność, to nie może być rzut na taśmę bez ana­li­zy i projektowania”.

Podstawową wyż­szo­ścią, dają­cą prze­wa­gę na ryn­ku, jest zwin­ność orga­ni­za­cji. SOA to nic inne­go jak taka wła­śnie struk­tu­ra sys­te­mu infor­ma­tycz­ne­go: spe­cja­li­zo­wa­ne apli­ka­cje, kom­po­nen­ty, insta­lo­wa­ne (wdra­ża­ne) do reali­za­cji kon­kret­nych potrzeb zaso­bów takich jak pra­cow­ni­cy księ­go­wo­ści, pra­cow­ni­cy sprze­da­ży, pra­cow­ni­cy pro­duk­cyj­ni, itp.. Co więc robić?

  1. Opisać stra­te­gie ryn­ko­wą firmy,
  2. Przeanalizować i opi­sać model biz­ne­so­wy (spo­sób powsta­wa­nia i źró­dło głów­nych dochodów),
  3. Uszczegółowić model biz­ne­so­wy do opi­su pro­ce­sów klu­czo­wych biz­ne­so­wych i reguł biznesowych,
  4. Wskazać pro­ce­sy, któ­rych wspar­cie meto­da­mi infor­ma­tycz­ny­mi przy­nie­sie mie­rzal­ne korzyści,
  5. Zaprojektować (udo­ku­men­to­wać) archi­tek­tu­rą sys­te­mu infor­ma­tycz­ne­go ukie­run­ko­wa­na na zaso­by i usługi.

Jeżeli pogo­dzi­my się z fak­tem, że SOA to usłu­go­wa archi­tek­tu­ra sys­te­mu infor­ma­tycz­ne­go fir­my, zaś wszel­kie webser­wi­sy, szy­ny itp. to tyl­ko moż­li­wa imple­men­ta­cji (ale nie jedy­na!) tej archi­tek­tu­ry to już będzie z gór­ki. (W co inwe­sto­wać w kry­zy­sie c.d. – SOA) 

Tak więc, jak mawia mój zna­jo­my pro­fe­sor filo­zo­fii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, kom­po­nen­tach, ana­li­zie i pro­jek­to­wa­niu zorien­to­wa­nym na usłu­gi mówi wie­lu. Dostawcy sys­te­mów ERP o zwar­tej, zin­te­gro­wa­nej archi­tek­tu­rze będą tu z natu­ry zacho­wy­wa­li bez­wład­ność: SOA powo­du­je, że żaden ERP (sys­tem i jego dostaw­ca) nie będzie miał mono­po­lu u raz pozy­ska­ne­go klienta.