Moim zda­niem błę­dem wie­lu pro­jek­tan­tów pro­gra­mów (sys­te­mów) jest mnie­ma­nie, że pro­jek­tu­ją biz­nes”. Nie! Projektują narzę­dzie biz­ne­su a to jest istot­na róż­ni­ca. Krawiec nie mode­lu­je i nie szy­je czło­wie­ka tyl­ko pro­jek­tu­je i szy­je to, co czło­wiek na sie­bie zało­ży, dla­te­go dobry gar­ni­tur musi mieć roz­po­rek ale już nie koniecz­nie kie­szeń na papier toa­le­to­wy. Jednak ten mane­kin musi być taki jak czło­wiek”, model biz­ne­su w opro­gra­mo­wa­niu także.

Kiedy i po co modelują?

Co to są te przy­pad­ki uży­cia? Najogólniej to lista czyn­no­ści, któ­re opi­su­je­my tak by pro­gra­mi­sta na ich pod­sta­wie wie­dział jakie funk­cjo­nal­no­sci ma reali­zo­wać pro­gram. Moja pra­ca nie raz doty­czy wyko­na­nia spe­cy­fi­ka­cji wyma­gań na sys­tem IT a to czę­sto są wła­śnie przy­pad­ki uży­cia. Praca moja na przy­pad­kach uży­cia się koń­czy. Dalej już pro­gra­mi­ści a ja nim nie jestem. Ale do rze­czy. Opis przy­pad­ków uży­cia jest tak na praw­dę zbio­rem pod­sta­wo­wych wyma­gań funk­cjo­nal­nych i musi być jed­no­znacz­ny, spój­ny i kompletny.

Jak ja sobie z tym radzę? 

Po wie­lu podej­ściach do two­rze­nia przy­pad­ków uży­cia uzna­łem, że nale­ży naj­pierw opi­sać co jest w ogó­le celem two­rze­nia tego sys­te­mu, co on ma wspo­ma­gać lub auto­ma­ty­zo­wać. Jak? Należy naj­pierw zamo­de­lo­wać tę wspo­ma­ga­ną czyn­ność w zupeł­nym ode­rwa­niu od sys­te­mów. Jak już zde­fi­niu­je­my i zop­ty­ma­li­zu­je­my samą czyn­ność moż­na zabie­rać się do wyszcze­gól­nia­nia przy­pad­ków uży­cia czy­li tak na praw­dę zapro­jek­to­wać tę dru­ga stro­nę lustra”.

Jak ja to robię? 

Tworzę model pro­ce­sów (uży­wam nota­cji i meto­dy­ki BPMN ale w prost­szych przy­pad­kach może to być np. dia­gram czyn­no­ści UML), od któ­re­go pro­po­nu­ję zacząć. Potem wska­zu­ję (wybie­ram) te czyn­no­ści, któ­re będą kom­pu­te­ry­zo­wa­ne” (bo nie koniecz­nie wszyst­kie). W meto­dy­ce któ­rą sto­su­ję jest poję­cie czar­nej skrzyn­ki. Jest to np. pro­jek­to­wa­ny jesz­cze hipo­te­tycz­ny sys­tem. Tworząc model pro­ce­sów łączę czar­ną skrzyn­kę z wybra­ny­mi czyn­no­ścia­mi (pro­ce­sa­mi) i opty­ma­li­zu­je tak powsta­ły model. Prosty przy­kład poniżej:

Proszę zwró­cić uwa­gę, że prze­ry­wa­ne linie od mode­lu do czar­nej skrzyn­ki to kom­plet­na lista przy­pad­ków uży­cia. Wystarczy je tyl­ko zebrać i udo­ku­men­to­wać np. tak jak w RUPie opi­so­wo za pomo­cą tabel lub struk­tu­ral­ne­go tak­stu. Podejście to wyma­ga trosz­kę wię­cej pra­cy ale ryzy­ko pomi­nię­cia cze­goś istot­ne­go jest mini­mal­ne dla­te­go war­to ten czas poświę­cić. Po dru­gie klient może łatwo taki model zwe­ry­fi­ko­wać i zatwier­dzić bo jest zro­zu­mia­ły dla nie­fa­chow­ców. Kto choć raz zetknął z odbio­rem sys­te­mu ten wie jak to ważne.

_______

2012: obec­nie sto­su­ję meto­dę prost­szą, ozna­cza­nie czyn­no­ści zakwa­li­fi­ko­wa­nych jako przy­pad­ki uży­cia, zamiast budo­wa­nia zło­żo­ne­go dia­gra­mu zawie­ra­ją­ce­go pulę System. Więcej o przej­ściu z mode­lu pro­ce­su na przy­pad­ki uży­cia.

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. Masz pytania to treści artykułu? Kliknij tu i umów się na krótkie konsultacje.

Dodaj komentarz

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