Pora na przy­pad­ki uży­cia i gra­ni­ce sys­te­mu. W poprzed­niej czę­ści (Diagram klas ? czy­li ?rein­ży­nie­ria? ana­li­zy biz­ne­so­wej) wska­za­łem na poten­cjal­ne ryzy­ka opi­su user sto­ry i narzę­dzie niwe­lu­ją­ce tę wadę czy­li model pro­ce­su jaki opi­sał Zamawiający (hipo­te­tycz­ny autor opi­su User sto­ry). Tworzenie mode­lu ma dwa zada­nia: wery­fi­ka­cja spój­no­ści i kom­plet­no­ści opi­su Zamawiającego oraz stwo­rze­nie pod­sta­wy do okre­śle­nia zakre­su pro­jek­tu i wyspe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych czy­li tak zwa­nych przy­pad­ków uży­cia. Czy tak się robi zawsze? Ja z zasa­dy (moja meto­dy­ka opra­co­wa­na na bazie doświad­czeń i lite­ra­tu­ry) trak­tu­ję KAŻDY opis, nawet w posta­ci struk­tu­ral­nej (tabe­le, punk­ty itp.), dostar­czo­ny przez Zamawiającego jako takie wła­śnie ryzy­kow­ne user sto­ry.

Czy to brak zaufa­nia dla Zamawiającego? Przecież to dla nie­go sys­tem, Zamawiający powi­nien umieć okre­ślić cze­go potrze­bu­je. Hm… każ­dy z nas potra­fi powie­dzieć do cze­go i jaki chce samo­chód, czy to zna­czy że potra­fi wyspe­cy­fi­ko­wać kon­struk­cję tego samo­cho­du? (mój mecha­nik jest bar­dziej dosad­ny, zawsze mówi: nie nic gor­sze­go od face­ta, któ­re­mu wyda­je się, że zna się na samo­cho­dach). Aby kupić goto­we opro­gra­mo­wa­nie o stan­dar­do­wej, powszech­nie sto­so­wa­nej funk­cjo­nal­no­ści, w zasa­dzie żaden ana­li­tyk nie jest nam potrzeb­ny. Jeżeli jed­nak chce­my coś, co choć trosz­kę ma paso­wać do nasze­go biz­ne­su i nie jest try­wial­ne nale­ży do tego podejść z więk­sza rezer­wą do wsze­la­kich oczy­wi­sto­ści, bo nie mówi­my już o prze­cięt­nym samo­cho­dzie ale o samo­cho­dzie, któ­rym wystar­tu­je­my w zawo­dach. Te zawo­dy to Wolny Rynek, star­cie z Konkurencją. Może nie zawsze jest to Formuła 1, ale też pra­wie nigdy nie jest to też jaz­da spa­ce­ro­wa na święta.

Wróćmy do nasze­go mode­lu pro­ce­sów. Ten, powsta­ły na bazie opi­su Zamawiającego pozwo­lił zna­leźć luki i nie­spój­no­ści, jest jed­nak zbyt szcze­gó­ło­wy. To rzad­ki u mnie przy­pa­dek ana­li­zy bot­tom-up (od szcze­gó­łu do ogó­łu) jed­nak pierw­sza sztyw­na zasa­da ana­li­ty­ka mówi: nie ist­nie­ją sztyw­ne zasa­dy ana­li­zy i pro­jek­to­wa­nia. Po drob­nych popraw­kach, uogól­nie­niu, model wyglą­da tak:

W zakre­sie pro­jek­tu mamy wszyst­kie czyn­no­ści, któ­re wraz z ich pro­duk­ta­mi sta­no­wią pro­ce­sy biz­ne­so­we, zosta­ły ona ozna­czo­ne ste­reo­ty­pem «usłu­ga apli­ka­cji» (ste­reo­ty­py nie są czę­ścią BPMN, moż­na je sto­so­wać do wska­za­nia powią­zań pomię­dzy obiek­ta­mi na mode­lach BPMN i UML gdzie będą im odpo­wia­da­ły przy­pad­ki użycia).

Po stro­nie Klienta (użyt­kow­ni­ka, dalej zwa­ne­go tak­że akto­rem) zasto­so­wa­no uprosz­cze­nie: jest mode­lo­wa­ny jak tak zwa­na czar­na skrzynka.

Będziemy bazo­wa­li na defi­ni­cji pro­ce­su biz­ne­so­we­go: pro­ces biz­ne­so­wy to czyn­ność lub logicz­nie powią­za­ny łań­cuch czyn­no­ści prze­kształ­ca­ją­cy pro­dukt na swo­im wej­ściu w pro­dukt (jego stan) na wyj­ściu. Różnica pomię­dzy tymi pro­duk­ta­mi sta­no­wi war­tość wno­szo­ną biz­ne­so­wą przez pro­ces.

Po stro­nie Sklepu mamy więc teraz pro­ce­sy (czyn­no­ści): Rejestracja Zamówienia, Rejestracja wpła­ty, Pakowanie i wysył­ka oraz Utworzenie rapor­tu o sta­nie zamówienia.

Kolejna rzecz to gra­ni­ce sys­te­mu. Dwa zało­że­nia, któ­re wyda­ją się bar­dzo roz­sąd­ne: Firma posia­da sys­tem ERP oraz płat­no­ści elek­tro­nicz­ne będą przed­mio­tem out­so­ur­cin­gu. Tak więc wyma­ga­nia na sys­tem to:

  1. przyj­mo­wa­nie zamówień,
  2. przyj­mo­wa­nie płat­no­ści dro­ga elektroniczną,
  3. inte­gra­cja z ERP: sys­tem ten odpo­wia­da za księ­go­wa­nie fak­tur i zarzą­dza­nie magazynem,
  4. uży­cie zewnętrz­ne­go ope­ra­to­ra płat­no­ści elektronicznych.

Powyższe wyda­je się roz­sąd­ne i bywa czę­sto spo­ty­ka­ne (sta­ram się by ten przy­kład aż tak nie odbie­gał od rze­czy­wi­sto­ści ;)). Wymagania powin­ny być zwię­złe ale tez nie powin­ny wykra­czać poza opis co powin­no być moż­li­we z nowym sys­te­mem. Tak więc dia­gram przy­pad­ków jaki stwo­rzy­łem uży­cia wyglą­da tak:

Kilka słów na temat tego dia­gra­mu. Mamy przy­pa­dek uży­cia dla każ­dej aktyw­no­ści. Każdy przy­pa­dek uży­cia powi­nien zostać udo­ku­men­to­wa­ny co naj­mniej trze­ma elementami:

  1. stan począt­ko­wy (warun­ki początkowe)
  2. sce­na­riusz
  3. ocze­ki­wa­ny stan końcowy

Kontekst sta­no­wi model pro­ce­sów wiec nie musi­my tu pisać czym są poprze­dza­ne i jakich mają następ­ców poszcze­gól­ne przy­pad­ki uży­cia. Wystarczy w mode­lach zacho­wać tak zwa­ne tra­ce­abi­li­ty (ja sto­su­ję pro­stą zasa­dę: nazwa przy­pad­ku uży­cia jest taka sama jak czyn­no­ści na mode­lu pro­ce­sów, z któ­rej został wypro­wa­dzo­ny, nazwy te są uni­kal­ne). Nie musi­my tak­że two­rzyć dia­gra­mów sce­na­riu­szy nad­rzęd­nych łań­cu­chów przy­pad­ków uży­cia bo zastę­pu­je je wła­śnie model BPMN. Na koniec uwa­ga: przy­pa­dek uży­cia powi­nien być samo­wy­star­czal­ny, inny­mi sło­wy musi mieć sens jako sam jeden (sam z sie­bie słu­ży do wyko­na­nia jakiejś logicz­nej czyn­no­ści dają­cej przy­dat­ny produkt).

Scenariusz naj­pro­ściej i naj­sku­tecz­niej jest opi­sy­wać w posta­ci dia­lo­gu Aktor <-> System. Ja sto­su­ję np. pro­sta tabe­lę z kolum­na­mi Aktor i System:

AKTOR                            SYSTEM
Inicjuje pracę                   Wyświetla listę produktów
Zaznacza wybrane produkty i OK   Wyświetla treść zamówienia
Potwierdza zamówienie            Wyświetla dane o płatności
Wybiera system płatności i OK    Kończy i ewentualnie przekazuje sterowanie

Tworzenie dia­gra­mów przy­pad­ków uży­cia w zasa­dzie war­to trak­to­wać tyl­ko jako spe­cy­fi­ka­cję kon­cep­cji zacho­wu­jąc zro­zu­mia­łość dla laika. Bąbelki powin­ny być tyl­ko spe­cy­fi­ka­cją funk­cjo­nal­ną i niczym ponad to. Ten dia­gram i tak nie zastą­pi dia­gra­mu klas, sekwen­cji czy tym bar­dziej opi­su pro­ce­su (tu był BPMN). Jak nie trud­no chy­ba już zauwa­żyć, doku­men­ta­cja zmie­rza w kie­run­ku kil­ku pro­stych mode­li (dia­gra­mów) zamiast jed­ne­go spa­ge­tii-mode­lu. Często spo­ty­kam się z doku­men­ta­mi, w któ­rych autor ana­li­zy wyma­gań wszyst­ko udo­ku­men­to­wał (sta­rał się) na dia­gra­mie przy­pad­ków uży­cia. To bywa straszne.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. Joanna

    Bardzo pro­szę o wsta­wie­nie obraz­ków. Aktualnie nie wyświe­tla­ją się.

    1. Jaroslaw Zelinski

      Tu tak­że napra­wi­łem bra­ki, prze­pra­szam za kło­pot i dzię­ku­je, za informację 🙂

Dodaj komentarz

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