W stycz­niu tego (2011) roku napi­sa­łem: Mamy więc ana­li­zę biz­ne­so­wą i spe­cy­fi­ko­wa­nie wyma­gań poprzez opra­co­wa­nie wery­fi­ko­wal­nych mode­li a nie tyl­ko listę potrzeb, któ­rej nie­ste­ty nie da się zwe­ry­fi­ko­wać co do kom­plet­no­ści i spój­no­ści bo nie ma narzę­dzia spraw­dza­ją­ce­go. Co jest takim narzę­dziem? Ano mode­le i to, że powsta­ły (jeże­li powsta­ły) przy pomo­cy sfor­ma­li­zo­wa­nej nota­cji. (źr. Analiza przed­wdro­że­nio­wa ? czym jest | Jarosław Żeliński – rynek IT, ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie sys­te­mów).

Przyszła pora na opi­sa­nie samej ana­li­zy. Skoro więc ana­li­za bazu­je na mode­lach, naj­czę­ściej dia­gra­mach, poku­si­łem się na, tym razem na nie­for­mal­ny dia­gram obra­zu­ją­cy ana­li­zę sys­te­mo­wą w kon­tek­ście inży­nie­rii oprogramowania.

Mamy dwa ele­men­ty tej ana­li­zy: ana­li­zę sys­te­mo­wą jako pro­ces głów­ny oraz mode­le jako narzę­dzia testo­wa­nia hipo­tez. W przy­pad­ku pro­jek­to­wa­nia celem jest pro­jekt rozwiązania.

Standardowym narzę­dziem sto­so­wa­nym przez więk­szość ana­li­ty­ków wyma­gań do prze­ka­za­nia wyma­gań na opro­gra­mo­wa­nie jest ich spe­cy­fi­ka­cja. Problem w tym, że pierw­szym testem tej spe­cy­fi­ka­cji jest tak na praw­dę dopie­ro ich implementacja.

Alternatywnym podej­ściem jest ana­li­za sys­te­mo­wa i mode­lo­wa­nie. Problem do roz­wią­za­nia to opra­co­wa­nie opro­gra­mo­wa­nia, któ­re zre­ali­zu­je cel zama­wia­ją­ce­go. Zamiast jed­nak, np. z pomo­cą wywia­dów, spi­sy­wać, nie pod­da­ją­ce się żad­nym testom, ocze­ki­wa­nia zama­wia­ją­ce­go, two­rzy­my dwa modele:

  1. naj­pierw model fir­my zama­wia­ją­ce­go by na nim prze­te­sto­wać zro­zu­mie­nie dzia­ła­nie samej fir­my i ewen­tu­al­nie ją nie­co zop­ty­ma­li­zo­wać”,
  2. model przy­szłe­go opro­gra­mo­wa­nia, któ­re ma zaspo­ko­ić potrze­by zama­wia­ją­ce­go czy­li zre­ali­zo­waw­szy jego cel.

Celem jest opro­gra­mo­wa­nie a dostaw­cy opro­gra­mo­wa­nia naj­mniej ryzy­ku­ją gdy dosta­ną jego spe­cy­fi­ku­ję czy­li goto­wy pro­jekt. Tak wiec prze­te­sto­wa­ny model opro­gra­mo­wa­nia reali­zu­ją­cy cel zama­wia­ją­ce­go jako wynik ana­li­zy sys­te­mo­wej sta­no­wi nic inne­go jak opis pro­duk­tu, któ­ry ma powstać. Oczywiście nikt nie pro­jek­tu­je od zera opro­gra­mo­wa­nia biz­ne­so­we­go bo to nie­roz­sąd­ne, wyko­rzy­stu­je się tak zwa­ne szkie­le­ty opro­gra­mo­wa­nia. O szkie­le­tach już było tu: Frameworks Introduction ? czy­li jak się psu­je dobre ERP. A teraz zapra­szam do obej­rze­nia tego co tu napi­sa­łem po moje­mu czy­li na dia­gra­mie 🙂 (tak zwa­ne mapy myśli cza­sa­mi sie przydają :)).

Warto tu zwró­cić uwa­gę na jed­ną rzecz: ewen­tu­al­ne zmia­ny roz­wią­za­nia i korek­ty mode­lu (czy­li pro­jek­tu) odby­wa­ją się nadal na eta­pie ana­li­zy i pro­jek­to­wa­nia, a wiec o rząd albo dwa taniej, niż pod­czas imple­men­ta­cji. Jest to głów­na prze­wa­ga tej meto­dy nad ana­li­zą w posta­ci sesji JAD ([[JAD, ang. Joint Application Development]] – ozna­cza współ­two­rze­nie apli­ka­cji, któ­re cza­sa­mi postrze­gam jako świa­do­me anga­żo­wa­nie klien­ta w pro­ces pro­jek­to­wa­nia by potem uczy­nić go współ­win­nym nie­po­wo­dze­nia) i opra­co­wy­wa­nia struk­tu­ral­nych dokumentów.

analiza systemowa oraz modelowanie jako jej główne narzędzie.

Jeżeli zre­zy­gnu­je­my z mode­li pozo­sta­je nam ryzy­kow­na sesja warsz­ta­to­wa (nie­jed­na):

Przygotowując warsz­tat zbie­ra­nia wyma­gań musisz być pewien, że zapro­sisz na nie­go wła­ści­we oso­by. Pamiętaj wte­dy, że:

  • Twoi bez­po­śred­ni klien­ci (pre­ze­si, dyrek­to­rzy, wła­ści­cie­le firm) czę­sto nie zna­ją tak napraw­dę potrzeb i kon­tek­stu pra­cy przy­szłych użyt­kow­ni­ków koń­co­wych zama­wia­ne­go systemu.
  • Użytkownicy koń­co­wi nie zawsze zna­ją i rozu­mie­ją potrze­bę biz­ne­so­wą dla two­rze­nia nowe­go oprogramowania.
  • Klienci i użyt­kow­ni­cy koń­co­wi nie zna­ją tech­no­lo­gii tak dobrze jak Ty i Twoja fir­ma, więc nie będą w sta­nie zro­zu­mieć szcze­gó­łów roz­wią­zań tech­nicz­nych w two­rzo­nym systemie.
  • Ty i Twoja fir­ma może­cie nie rozu­mieć w peł­ni potrzeb klien­ta i pro­ble­mu, któ­ry two­rzo­ne opro­gra­mo­wa­nie ma rozwiązać.

Co z tym zro­bić? Pamiętaj, aby zadbać, żeby przed­sta­wi­cie­le wszyst­kich powyż­szych grup bra­li udział w warsz­ta­tach, wów­czas inte­res każ­dej ze stron będzie repre­zen­to­wa­ny. (źr. ser­wis O wymaganiach)

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 10 komentarzy

  1. Jakub Jurkiewicz

    Chyba cze­goś nie rozu­miem w Twoim podej­ściu. Przygotowujesz naj­pierw obec­ny model fir­my, a póź­niej model koń­co­wy po wdro­że­niu opro­gra­mo­wa­nia, tak? Wytłumacz mi pro­szę w jaki spo­sób naj­pierw zbie­rasz infor­ma­cje na temat sta­nu obec­ne­go, a tak­że na temat jaki pro­blem opro­gra­mo­wa­nie ma roz­wią­zać? Unikasz spo­tkań z klien­tem albo z użyt­kow­ni­ka­mi końcowymi?
    Cel warsz­ta­tu może być róż­ny, ale jed­ną z jego cech jest to, że na koniec takie­go spo­tka­nia powin­ni­śmy coś uzgod­nić (np. zakres pro­jek­tu) lub coś wspól­nie stwo­rzyć (np. model przy­pad­ków uży­cia, dia­gram kon­tek­stu, model biz­ne­so­wy klienta).
    Dla mnie więk­szym ryzy­kiem jest brak kon­sul­ta­cji z klien­tem i użyt­kow­ni­ka­mi koń­co­wy­mi niż kil­ka spo­tkać z nimi w celu lep­sze­go zro­zu­mie­nia ich potrzeb. Uważasz, że lepiej jest same­mu stwo­rzyć wszyst­kie mode­le, a póź­niej imple­men­ta­cję i dopie­ro na koń­cu przyjść do klien­ta i poka­zać mu co zrobiłeś?

    1. Jarek Żeliński

      Być może uprosz­cze­nie nam zaszko­dzi­ło”… :). Podchodzę do pro­ble­mu wyma­gań tak jak lekarz (to tak­że pew­ne uogól­nie­nie): pytam ogól­nie pacjen­ta jaki ma pro­blem, potem robię obiek­tyw­ne bada­nia (krew, mocz, prze­świe­tle­nie itp.), czy­li coś co jest nie­za­leż­ne od jego subiek­tyw­ne­go odczu­cia cho­ro­by. Ewentualne nie­ja­sno­ści wyja­śniam dopie­ro w krót­kiej roz­mo­wie. Staram się zro­zu­mieć jego orga­nizm i jego stan a nie to co mówi pacjent. Problem w tym, że opo­wia­da­nie to wynik tego co widzi (rozu­mie) opo­wia­da­ją­cy i jego dotych­cza­so­wych (i tyl­ko jego) doświad­czeń (psy­cho­lo­gia, teo­ria komu­ni­ka­cji społecznej).

      Analizę pro­wa­dzę tak: pytam spon­so­ra pro­jek­tu co chce osią­gnąć, pro­szę o plan mar­ke­tin­go­wy i stra­te­gię (jak ich nie ma robię je sam z ich pomo­cą), zbie­ram doku­men­ty jakich uży­wa orga­ni­za­cja i na ich pod­sta­wie odtwa­rzam jej model infor­ma­cyj­ny (tak­so­no­mia) i pro­ce­sy. Taki model jest potem testo­wa­ny z udzia­łem kadr kierowniczych.

      Na goto­wym mode­lu nano­szę zakres pro­jek­tu, w obsza­rze zakre­su uszcze­gó­ła­wiam pro­ce­sy, dalej czyn­no­ści w pro­ce­sach obję­tych zakre­sem pro­jek­tu są mapo­wa­ne na przy­pad­ki uży­cia (są z nich wywo­dzo­ne). Równolegle, na bazie doku­men­tów w pro­ce­sach, powsta­je model dzie­dzi­ny dla MVC. Każdy nie­try­wial­ny przy­pa­dek uży­cia otrzy­mu­je model sekwen­cji, Model Dziedziny uzu­peł­nia­ny jest o meto­dy i atry­bu­ty klas.

      Po testach mode­li, otrzy­mu­ję model będą­cy kon­cep­cją roz­wią­za­nia. Jest to typo­we” MDD (Model Driven Design). Metoda ma tę zale­tę, że wyma­ga­nia są dość odpor­ne na subiek­ty­wizm pra­cow­ni­ków zama­wia­ją­ce­go, mało anga­żu­ją jego ludzi a ryzy­ko nie­od­kry­tych wyma­gań jest minimalne.

      Tak wiec pro­ces Analizy Systemowej ma w cen­tral­nej czę­ści mode­le i ich testo­wa­nie, te mode­le to kolej­no model pro­ce­sów biz­ne­so­wych (BPMN) i model opro­gra­mo­wa­nia UML). Wymaganiem jest ten ostatni.

  2. Jakub Jurkiewicz

    Dzięki za wyja­śnie­nie, teraz już lepiej rozu­miem Twoje podej­ście, cho­ciaż nadal mam swo­je wąt­pli­wo­ści i wyda­je mi się, że nie słusz­nie kry­ty­ku­jesz nie­któ­re z opi­sy­wa­nych prze­ze mnie pomy­słów. Tutaj aku­rat piszesz o warsz­ta­tach, ale to wła­śnie takie warsz­ta­ty możesz wyko­rzy­stać do wery­fi­ka­cji swo­ich modeli.
    Piszesz, że wolisz obser­wo­wać niż roz­ma­wiać, bo to co klient mówi to jest jego subiek­tyw­na opi­nia. I wła­śnie po to mogą być wyko­rzy­sta­ne warsz­ta­ty, na któ­re oprócz klien­ta zapra­szasz użyt­kow­ni­ków koń­co­wych, eks­per­tów z danej dzie­dzi­ny, pro­gra­mi­stów, archi­tek­ta, itp. – to poma­ga lepiej zro­zu­mieć pro­blem zarów­no ana­li­ty­kom jak i klien­to­wi, poma­ga odkryć nowe wyma­ga­nia, ina­czej spoj­rzeć na nie­któ­re spra­wy, pozwa­la odkryć kon­flik­ty w ocze­ki­wa­niach (szcze­gól­nie mię­dzy spon­so­rem pro­jek­tu a użyt­kow­ni­ka­mi końcowymi).
    Zastanawiam się też jak wyglą­da testo­wa­nie mode­li. Każda kadra kie­row­ni­cza jest w sta­nie w łatwy spo­sób zro­zu­mieć dia­gra­my UML?

    1. Jarek Żeliński

      Jeżeli ode­bra­łeś to jak kry­ty­kę to prze­pra­szam, moją inten­cją jest poka­za­nie cze­goś inne­go dla prze­ciw­wa­gi, innej – tak­że (może mniej powszech­nie) sto­so­wa­nej – meto­dy. Niewątpliwie są przy­pad­ki gdy każ­da ma swo­je zasto­so­wa­nie, ja raczej bro­nie tezy, mówią­cej, że jeśli kupu­ją­cy nie rozu­mie tech­no­lo­gii, któ­rą kupu­je nie powi­nien brać udzia­łu w jej two­rze­niu, powi­nien być uczest­ni­kiem opi­sy­wa­nia ocze­ki­wań, ale już nie two­rze­nia tego co zamó­wił (choć może to brzmieć dziw­nie)… Są sytu­acje, gdy JAD się spraw­dza ale też, nie wyobra­żam sobie by tele­wi­zor powstał na bazie sesji z przy­szły­mi oglą­da­cza­mi meczy piłkarskich. 

      Jakiś czas temu wpa­dła mi w rękę książ­ka Fowlera, w któ­rej wstę­pie napi­sał on ideę meto­dy opart­nej na mode­lach (MDD):

      Wyobraźmy sobie kogoś, kto chce napi­sać pro­gram, 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­ną 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 symu­la­cji. 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.”

      Rzecz w tym, że od gra­cza w sno­oke­ra na pew­no dowiesz tyl­ko tego co chce on osią­gnąć jako gracz, ale raczej nie poznasz praw fizy­ki, dzię­ki któ­rym on w ogó­le może tak grać jak chce…

      Dlatego w sys­te­mach dla biz­ne­su zakła­dam, że bar­dzo rzad­ko wszy­scy pra­cow­ni­cy zna­ją się na ryn­ku, prze­wa­dze ryn­ko­wej czy rachun­ko­wo­ści, mimo tego, że maja duży udział w suk­ce­sie swo­jej firmy…

      Odpowiadając: jeśli poja­wi się kon­flikt pomię­dzy spon­so­rem pro­jek­tu a użyt­kow­ni­kiem to jest to z defi­ni­cji pro­blem poza­in­for­matcz­ny… tu kom­pe­ten­cja­mi są nego­cja­cje a nie inży­nie­ria opro­gra­mo­wa­nia, w prze­ciw­nym wypad­ku nara­ża­my się pozy­cje mię­dzy mło­tem a kowadłem…

      Testowanie mode­li: model pro­ce­sów biz­ne­so­wych w fir­mie (BPMN) testu­ję z jej pra­cow­ni­ka­mi, ale mode­le UML pro­jek­tu opro­gra­mo­wa­nia po pro­tu testu­je sam lub z programistami.

      Jest to inna meto­da, czy lep­sza czy gor­sza to kwe­stia pro­jek­tu. Mam wra­że­nie, że pro­jek­tach biz­ne­so­wych, gdzie celem opro­gra­mo­wa­nia jest wspie­ra­nie zarzą­dza­nia w fir­mie spraw­dza się lepiej…

  3. Jakub Jurkiewicz

    Teraz już znacz­nie lepiej rozu­miem Twoje podej­ście. Wydawało mi się przez chwi­lę, że cał­ko­wi­cie kry­ty­ku­jesz podej­ście ści­ślej­szej współ­pra­cy z klien­tem. Zgadzam się z Tobą, że są róż­ne pro­jek­ty, w nie­któ­rych zapew­ne Twoje podej­ście spraw­dza się bar­dzo dobrze, jed­nak wyda­je mi się, że są sytu­acje, kie­dy bliż­sza współ­pra­ca z klien­tem może dać lep­sze efekty.

    Dziękuję za wyjaśnienie.

    1. Jarek Żeliński

      Sytuacji, w któ­rych spraw­dza się podej­ście sta­łe­go kon­tak­tu z klien­tem jest dużo, moim zda­niem zawsze tam gdzie celem pro­jek­tu jest wła­śnie subiek­ty­wizm zama­wia­ją­ce­go, któ­ry nie musi być racjo­nal­ny a mimo to jest sku­tecz­ny, w szcze­gól­no­ści chy­ba pro­jek­ty zwią­za­ne ze stro­na­mi WWW, pro­gra­ma­mi lojal­no­ścio­wy­mi, akcja­mi pro­mo­cyj­ny­mi itp. Bał bym się jed­nak ta meto­dą wdra­żać sys­te­my rapor­to­we, zarzą­dza­nie prze­pły­wem pra­cy czy zaawan­so­wa­ne sys­te­my CRM (czym by nie były…;)), po pro­tu sys­tem, któ­re­go zło­żo­ność prze­kra­cza moż­li­wo­ści pro­stej wyobraź­ni typo­we­go czło­wie­ka wyma­ga (podob­nie jak kule sno­oke­ra) inne­go podej­ścia niż ankiety.

  4. Jakub Jurkiewicz

    P.S. Dlaczego przy moich komen­ta­rzach poja­wia się taka roz­złosz­czo­na mordka? 😉

    1. Jarek Żeliński

      te mord­ki są gene­ro­wa­ne loso­wo każ­de­mu komen­tu­ją­ce­mu, nie mam wpły­wu na wynik loso­wa­nia :D.

    2. Kinga Sęk

      czy to jest cała część ana­li­zy systemowej ?

    3. Jarek Żeliński

      To jest to, co nazy­wa się Analiza Systemowa, któ­rej źró­dło tkwi w Ogólnej Teorii Systemów (nie nale­ży tego utoż­sa­miać z Systemami Informatycznymi).

Dodaj komentarz

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