Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie

Ronald Ross, współ­au­tor stan­dar­du mode­lo­wa­nia reguł biz­ne­so­wych i biz­ne­so­we­go słow­ni­ka pojęć napi­sał nie­daw­no na swo­im pro­fi­lu LinkedIn:

People love sto­ries. Are user sto­ries help­ful in engi­ne­ering busi­ness solu­tions? Absolutely. Are you done with requ­ire­ments and solu­tion engi­ne­ering when you’ve wor­ked thro­ugh a set of user sto­ries? No. Not even clo­se!” [„Ludzie kocha­ją histo­rie. Czy histo­rie użyt­kow­ni­ków są pomoc­ne w two­rze­niu roz­wią­zań biz­ne­so­wych? Zdecydowanie tak. Czy skoń­czy­łeś z wyma­ga­nia­mi i inży­nie­rią roz­wią­za­nia, gdy już opra­co­wa­łeś zestaw histo­ry­jek użyt­kow­ni­ka? Nie. Nawet nie zbli­ży­łeś się do nich!”.]

(https://​www​.lin​ke​din​.com/​p​o​s​t​s​/​r​o​s​s​r​o​n​a​l​d​_​p​e​o​p​l​e​-​l​o​v​e​-​s​t​o​r​i​e​s​-​a​r​e​-​u​s​e​r​-​s​t​o​r​i​e​s​-​h​e​l​p​f​u​l​-​a​c​t​i​v​i​t​y​-​6​9​3​5​6​2​7​0​0​8​2​6​5​6​3​3​7​9​3​-​B​p​zb/)

Świat od dekad bory­ka się z jako­ścią i sku­tecz­no­ścią spe­cy­fi­ko­wa­nia wyma­gań na opro­gra­mo­wa­nie. OMG​.org opu­bli­ko­wa­ło stan­dard o nazwie MDA (ang. Model Driven Architecture ), któ­ry tak opi­su­je pro­ces two­rze­nia oprogramowania:

CIM -> PIM -> PSM

Są to odpo­wied­nio mode­le: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu dzia­ła­nia (PIM: Platform-Independent Model, jest to model dzie­dzi­ny sys­te­mu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego cza­su sze­rzej opi­sa­łem zależ­no­ści mię­dzy tymi mode­la­mi (czy­taj wię­cej o MDA).

CIM to model dzia­ła­nia orga­ni­za­cji: pro­ce­sy biz­ne­so­we i ich pro­duk­ty. Z uwa­gi na to, że obec­nie już nie rodzą się pro­jek­ty jed­no­ra­zo­wej infor­ma­ty­za­cji cało­ści orga­ni­za­cji, poja­wia się potrze­ba okre­śle­nia zakre­su pro­jek­tu, bo nie jest już nim cała orga­ni­za­cja. Model PIM to udo­ku­men­to­wa­ny mecha­nizm dzia­ła­nia sys­te­mu (opro­gra­mo­wa­nia), logi­ka jego dzia­ła­nia. Nie ma tu mowy o tym w jakiej tech­no­lo­gii powsta­nie, bo z zasa­dy mamy ich wie­le do wybo­ru, a wybór tech­no­lo­gii zale­ży od wie­lu poza-funk­cjo­nal­nych ogra­ni­czeń i wyma­gań. Technologia jest (powin­na być) kon­se­kwen­cją wybo­ru wyko­naw­cy i ten dopie­ro opra­cu­je model PSM, któ­ry w prak­ty­ce jest tak zwa­ną Koncepcją Wdrożenia, moż­na ją tak­że udo­ku­men­to­wać w nota­cji UML, ale na tym eta­pie powszech­na prak­ty­ką jest jedy­nie zapro­jek­to­wa­nie śro­do­wi­ska, zesta­wie­nie go i pra­ca od razu w kodzie.

Kluczowym pro­ble­mem jest przej­ście z CIM na PIM, czy­li jak udo­ku­men­to­wać zakres pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia i prze­kształ­cić go na wyma­ga­nia wobec tego oprogramowania?

CIM -> [zakres pro­jek­tu] -> PIM -> PSM

W meto­dach zwa­nych zwin­ny­mi, mode­le CIM i PIM są pomi­ja­ne. Typowym zaś narzę­dziem zbie­ra­nia wyma­gań” są tak zwa­ne histo­ryj­ki użyt­kow­ni­ka (user sto­ry). Problem w tym, że są one klu­czo­wym ryzy­kiem pro­jek­tów gdyż z regu­ły są nie­spój­ne i nie­kom­plet­ne jako wyma­ga­nia. Specyfikacja wyma­gań powin­na być: spój­na, kom­plet­na i nie­sprzecz­na. Opisanie zakre­su pro­jek­tu histo­ryj­ka­mi użyt­kow­ni­ka, nie mając mode­lu pro­ce­sów biz­ne­so­wych cało­ści (model CIM), jest pozba­wie­niem się narzę­dzia do wery­fi­ka­cji kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji. Wszystkie wady (nie­kom­plet­ność, nie­spój­ność, sprzecz­no­ści) odkry­wa­ne są i usu­wa­ne (uzu­peł­nia­ne) dopie­ro na eta­pie wdra­ża­nia. Jest to pro­ces odkry­wa­nia wyma­gań w toku wdrożenia”. 

Historyjki użyt­kow­ni­ka jako lista potrzeb biz­ne­so­wych? Owszem! Historyjki użyt­kow­ni­ka jako wyma­ga­nia dla deve­lo­pe­ra? NIE! To tyl­ko mate­riał dla pro­jek­tan­ta, ponie­waż bar­dzo czę­sto jed­na i ta sama funk­cja sys­te­mu reali­zu­je wie­le róż­nych histo­rii użyt­kow­ni­ka. Implementacja per user sto­ry” pro­wa­dzi do bar­dzo kosz­tow­nych i nie­efek­tyw­nych roz­wią­zań (Opisywałem to na blo­gu: wpis pro­jekt Biblioteka, dwie histo­ryj­ki użyt­kow­ni­ka: chciał­bym wypo­ży­czyć książ­kę oraz chciał­bym zwró­cić książ­kę są reali­zo­wa­ne jed­ną usłu­gą apli­ka­cji: Karta Wypożyczenia, któ­ra zawie­ra rów­nież pole Data zwro­tu. Nadal spo­ty­kam pro­gra­mi­stów prze­ko­nu­ją­cych, że powin­ny to być dwa osob­ne ekra­ny – dwa przy­pad­ki uży­cia, czy­taj dwa razy wię­cej pra­cy kode­ra i dwa razy więk­szy koszt).

Czy można sformalizować proces zbierania historyjek użytkownika?

User Story to jed­no z naj­bar­dziej pro­ble­ma­tycz­nych narzę­dzi w meto­dach zwin­nych. Najczęściej zale­ca­na struk­tu­ra tych histo­ry­jek”, wraz z przykładami:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Na przy­kład:

Jako Administrator chcę otrzy­my­wać wia­do­mość e‑mail, gdy zosta­nie prze­sła­ny for­mu­larz kon­tak­to­wy, abym mógł na nie­go odpowiedzieć”

albo

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”;

Tak spi­sy­wa­ne wyma­ga­nia sta­no­wią ogrom­ny pro­blem z powo­du nie­rów­nej gra­da­cji, spro­wa­dza­nie ich do pozio­mu tak zwa­nych ato­mo­wych user sto­ry (dru­gi z powyż­szych przy­kła­dów) pro­wa­dzi do bar­dzo dużych liczb tych histo­ry­jek. Próba ich wery­fi­ka­cji (wali­da­cja user sto­ry) sta­je się co naj­mniej trud­nym zada­niem. Jakakolwiek wyce­na opro­gra­mo­wa­nia na bazie takich histo­ry­jek to wró­że­nie z fusów (więc deve­lo­pe­rzy moc­no zawy­ża­ją wyce­ny z uwa­gi na ryzy­ko utra­ty ren­tow­no­ści). Autorzy inne­go opra­co­wa­nia zauważają:

Rzeczywiście, przy oko­ło 800 US [User Story], hie­rar­chia była raczej trud­na do okre­śle­nia, a obraz sys­te­mu pod­czas pla­no­wa­nia był bar­dzo duży. Skalowalność jest więc zde­cy­do­wa­nie pro­ble­mem w pro­jek­tach zwin­nych, w któ­rych US są sła­by­mi arte­fak­ta­mi inży­nie­rii wyma­gań. Zdecydował się on [autor] na wpro­wa­dze­nie wzor­ca US: Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zde­fi­nio­wać hie­rar­chię w posta­ci Celu, Zadania i Użytkownika, ale bez powią­za­nia semantycznego.

Znam pro­jekt, w któ­rym licz­ba przy­pad­ków uży­cia, w pew­nym śred­niej tyl­ko wiel­ko­ści pro­jek­cie, szyb­ko się­gnę­ła czte­ry­stu. Wycena na ich pod­sta­wie poka­za­ła, że pla­no­wa­ny koszt wie­lo­krot­nie prze­kra­cza pla­no­wa­ny budżet. Ten pro­jekt zarzu­co­no, jed­nak wie­le tak wyce­nio­nych pro­jek­tów jest reali­zo­wa­nych, co daje obraz ska­li strat jakie przy­no­szą (zawy­żo­ny koszt to stra­ta). Powyżsi auto­rzy piszą na zakończenie:

Przyszłe pra­ce obej­mu­ją iden­ty­fi­ka­cję luk repre­zen­ta­cyj­nych, któ­re napo­ty­ka­ją prak­ty­cy w mode­lo­wa­niu US, oraz prze­gląd spo­so­bów, w jakie nasze ramy i [meto­da] GORE w ogó­le mogły­by roz­wią­zać te pro­ble­my. Równolegle oce­nia­na będzie rów­nież zdol­ność prak­ty­ków do sto­so­wa­nia pro­po­no­wa­nych ram zamiast zwy­kłych sza­blo­nów. Obecnie trwa­ją pra­ce nad narzę­dziem CASE (Computer Aided Software Engineering), któ­re zosta­nie wyko­rzy­sta­ne do wspar­cia eksperymentów.

Nie zna­la­złem wyni­ków dal­szych prac, więc podzie­lę się wyni­ka­mi swoich.

Gradacja User Story

Podstawowym pro­ble­mem z user sto­ry jest, moim zda­niem, brak stan­dar­du pozwa­la­ją­ce­go na zde­fi­nio­wa­nie ato­mo­wej histo­ryj­ki użyt­kow­ni­ka” czy­li pozio­mu, poni­żej któ­re­go nie dzie­li­my ich na mniej­sze. Jako audy­tor wie­lu doku­men­ta­cji (czę­sto w roli bie­głe­go) zauwa­ży­łem, że histo­ryj­ki użyt­kow­ni­ka są dopro­wa­dza­ne do pozio­mu poje­dyn­czych kro­ków sce­na­riu­szy przy­pad­ków uży­cia. Często też histo­ryj­ki użyt­kow­ni­ka utoż­sa­mia­ne są z przy­pad­ka­mi uży­cia (UML) i tak mode­lo­wa­ne, co jest poważ­nym błę­dem. Np. powyższe: 

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”

Mogło by to być czę­ścią sce­na­riu­sza usłu­gi (przy­pa­dek uży­cia UML), któ­rej celem jest Pokazanie Określonego Miejsca:

  1. AKTOR ini­cju­je usłu­gę Cel podróży
  2. SYSTEM wyświe­tla for­mu­larz Adres
  3. AKTOR wpro­wa­dza dane i naci­ska OK
  4. SYSTEM wyświe­tla mapę z nanie­sio­ną lokalizacją
  5. AKTOR kli­ka okre­ślo­ny punkt na mapie 
  6. SYSTEM powięk­sza obraz poka­zu­jąc deta­le lokalizacji

Powyższa histo­ryj­ka to jedy­nie punkt 5. tego sce­na­riu­sza. Nie trud­no dojść do wnio­sku, że samo klik­nię­cie na mapie to pozba­wio­na kon­tek­stu i celu, wyrwa­na pro­sta czyn­ność, i jej samo­dziel­ne ist­nie­nie w spe­cy­fi­ka­cji jako osob­ny byt, pozba­wio­ne jest sen­su. Z per­spek­ty­wy opro­gra­mo­wa­nia powsta­ją­ce­go w okre­ślo­nym celu, uzna­nie tej histo­ryj­ki za samo­dziel­ne wyma­ga­nie nie ma uza­sad­nie­nia. Uznanie jed­nak, że apli­ka­cja słu­ży mię­dzy inny­mi do zapo­zna­wa­nia się okre­ślo­ny­mi miej­sca­mi w prze­strze­ni, a usłu­gą tej apli­ka­cji jest Pokazanie Określonego Miejsca jak naj­bar­dziej ma sens. Idąc za suge­stią by histo­ryj­ka użyt­kow­ni­ka mia­ła strukturę: 

Jako [Użytkownik], chcę [Zadanie], aby [Cel]”

zmu­sza do zasta­no­wie­nia się czy kli­ka­nie na mapie jest celem, czy może jed­nak tym celem jest Pokazanie Określonego Miejsca, a kli­ka­nie jest ele­men­tem sce­na­riu­sza (pro­ce­du­ry) reali­za­cji tego celu (pamię­ta­my, że przy­pad­ki uży­cia mają sce­na­riu­sze, a te zło­żo­ne są z sekwen­cji kolej­nych kroków!).

Formalizacja User Story

Pojęcia Użytkownik, Zadanie, Cel, jako spój­ny zestaw pojęć odpo­wia­da­ją defi­ni­cji ato­mo­we­go (ele­men­tar­ne­go) pro­ce­su w nota­cji BPMN (doda­tek C, Słownik , ): Aktywność jest sko­ja­rzo­na z jej wyko­naw­cą (pula, tor), two­rzy pro­dukt (data object). Biorąc pod uwa­gę fakt, że pro­dukt ma tu okre­ślo­ne­go adre­sa­ta i musi on sta­no­wić sobą war­tość dla tego adre­sa­ta, mamy punkt wyzna­cza­ją­cy gra­ni­cę dzie­le­nia na czę­ści” tych histo­ry­jek. Nie będzie to moż­li­wość wsta­wie­nia z listy nume­ru NIP nabyw­cy” a utwo­rze­nie fak­tu­ry” (bo war­tość ma dopie­ro popraw­nie wysta­wio­na fak­tu­ra, a nie klik­nię­cie np. w pole NIP by wybrać kontrahenta). 

Jak sfor­ma­li­zo­wać histo­ryj­kę użyt­kow­ni­ka? Podstawą for­ma­li­za­cji (i celem) jest opra­co­wa­nie meto­dy kon­tro­li popraw­no­ści (wali­da­cja). Popatrzmy jesz­cze raz na szablon:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Typ użyt­kow­ni­ka to rola, celem jest pro­dukt pra­cy, a powo­dem? Powodem jest zawsze to, że okre­ślo­na oso­ba ocze­ku­je na efekt tej pra­cy (bez tego pra­ca ta była­by po pro­stu zbęd­na). Można więc wyobra­zić sobie taki zapis:

Jako sprze­daw­ca, chcę wysta­wić fak­tu­rę, klientowi. 

Mamy tu:

  1. rola: sprze­daw­ca
  2. cel: fak­tu­ra
  3. powód: ocze­ku­je tego klient. 

W tym miej­scu widać peł­ną zgod­ność tej defi­ni­cji z kon­struk­cją: aktyw­ność, jej pro­dukt, jego odbior­ca. Innymi sło­wy ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych wyko­na­ny w nota­cji BPMN, to nic inne­go jak połą­czo­ne w logicz­ne cią­gi histo­ryj­ki użytkownika. 

Wyobraźmy sobie taką listę histo­ry­jek użyt­kow­ni­ka, wyko­na­ną wg. powyż­sze­go opisu:

Specyfikacja histo­ry­jek użytkownika

Niektóre narzę­dzia CASE, pozwa­la­ją­ce na ich pro­fi­lo­wa­nie, pozwa­la­ją przed­sta­wić to tak­że na mode­lu wyma­gań (co póź­niej umoż­li­wia śla­do­wa­nie, czy­li kon­tro­lę kom­plet­no­ści, spój­no­ści i niesprzeczności):

Diagram wyma­gań (nota­cja SysML)

Powyższe mogło­by być kon­se­kwen­cją takie­go mode­lu procesów:

Diagram pro­ce­su reali­za­cji zamó­wie­nia (nota­cja BPMN).

Jak widać, model pro­ce­su daje peł­ny kon­tekst dla aktyw­no­ści. Fakt, że pro­ces to logicz­ny prze­pływ pra­cy, powo­du­je, że two­rze­nie mode­li BPMN gwa­ran­tu­je spój­ność, kom­plet­ność i nie­sprzecz­ność listy aktyw­no­ści, ich pro­duk­tów i ról. 

Podsumowanie

Stosowanie typo­wych histo­ry­jek użyt­kow­ni­ka ma dwie klu­czo­we wady: 1. nie ma jed­nej meto­dy zarzą­dza­nia ich gra­da­cją i struk­tu­rą, wie­lu auto­rów przy­wo­łu­je wła­sne, nie­co się róż­nią­ce meto­dy stan­da­ry­za­cji, 2. ich dro­bia­zgo­wość oraz brak meto­dy kon­tro­li spój­no­ści, pro­wa­dzą do szyb­ko rosną­cej ich licz­by, w kon­se­kwen­cji cha­osu, szcze­gól­nie w śred­nich i więk­szych projektach.

Powyżej widać, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie zebra­nych przy­kła­do­wych doku­men­tów (pro­duk­ty pra­cy ludzi: doku­men­ty) i opra­co­wa­nie na ich pod­sta­wie dia­gra­mu przy­pad­ków uży­cia, daje znacz­nie lep­sze wyni­ki niż zbie­ra­ne na warsz­ta­tach histo­ryj­ki użyt­kow­ni­ka. Same wyma­ga­nia wyra­żo­ne jako histo­ryj­ki użyt­kow­ni­ka, nie dają żad­nej szan­sy (brak meto­dy) na kon­tro­lę ich spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści. Wymagania, jako kon­se­kwen­cja popraw­nie wyko­na­nych mode­li pro­ce­sów biz­ne­so­wych, z zasa­dy są spój­ne, kom­plet­ne i niesprzeczne.

W przy­to­czo­nym tu przy­kła­dzie widać, że dwie aktyw­no­ści (reje­stra­cja zamó­wie­nia i kon­tro­la jego sta­tu­su) reali­zo­wa­ne są jako dostęp do zapi­sa­ne­go w sys­te­mie Zamówienia. Daje to jasną prze­słan­kę do tego, że dwie histo­ryj­ki użyt­kow­ni­ka (dwie aktyw­no­ści na mode­lu pro­ce­sów) to dwa róż­ne kon­tek­sty uży­cia tej samej usłu­gi apli­ka­cji: Zamówienia (czy­li dostęp do ich two­rze­nia, aktu­ali­za­cji i pod­glą­du, to typo­wy przy­pa­dek uży­cia typu CRUD). Prawa dostę­pu do tego doku­men­tu mode­lu­je się zaś regu­ła­mi biz­ne­so­wy­mi (nie poka­za­no ich na dia­gra­mach), np. Klient ma wgląd tyl­ko w Zamówienia, któ­re sam złożył”. 

Można uznać, że małe pro­jek­ty, o małym ryzy­ku cha­osu wywo­ła­ne­go bra­kiem mode­li pro­ce­sów, moż­na reali­zo­wac na skró­ty” czy­li histo­ryj­ki użyt­kow­ni­ka i od razu model PSM (imple­men­ta­cja) z pomi­nię­ciem CIM i PIM, jed­nak jest to poważ­ne ryzy­ko już przy śred­nich pro­jek­tach. Dlatego pro­ces MDA:

{CIM -> [zakres pro­jek­tu] -> PIM} -> PSM

wyda­je się być znacz­nie efek­tyw­niej­szy co poka­zu­je prak­ty­ka (w nawia­sach klam­ro­wych {} zakres pra­cy analityka-projektanta).

Zakres pro­jek­tu to albo całe pro­ce­sy biz­ne­so­we albo świa­do­mie wybra­ne ich okre­ślo­ne aktyw­no­ści. Nie jest to tak­że żaden wodo­spad” (water­fall), bo ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych powsta­nie szyb­ciej i taniej niż lista setek histo­ry­jek z pomo­cą wie­lo­dnio­wych warsz­ta­tów anga­żu­ją­cych całe zespo­ły ludzi. Wygenerowane z mode­lu pro­ce­sów biz­ne­so­wych przy­pad­ki uży­cia, są z zasa­dy spój­ne i kom­plet­ne, więc ich ite­ra­cyj­ne (kolej­ne) spe­cy­fi­ko­wa­nie (każ­dy pro­jek­tu­je­my jako samo­dziel­ny mikro­ser­wis) pozwa­la bez ryzy­ka odda­wać je kolej­no do imple­men­ta­cji, i jed­no­cze­śnie doku­men­to­wać (uszcze­gó­ła­wiać) kolejne. 

To spraw­dzo­na w prak­ty­ce meto­da wspie­ra­na przez wie­le narzę­dzi CASE (wszyst­kie dia­gra­my i ich prze­kształ­ce­nia poka­za­ne w tym arty­ku­le powsta­ły z uży­ciem Visual-Paradigm). Diagram przy­pad­ków uży­cia UML jest tu auto­ma­tycz­nie gene­ro­wa­ny z mode­li BPMN, wg poniż­szych zasad:

BPMNtoUseCase (źr. http://​www​.visu​al​-para​digm​.com/​t​u​t​o​r​i​a​l​s​/​f​r​o​m​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​t​o​-​u​s​e​-​c​a​s​e​s​.​jsp)

Po tej ope­ra­cji wystar­czy spraw­dzić kon­tek­sty doku­men­tow i skon­so­li­do­wać w jeden ewen­tu­al­ne nad­mia­ro­we przy­pad­ki uży­cia. I na koniec:

Jeśli nie masz mode­li poję­cio­wych, bra­ku­je Ci waż­ne­go ele­men­tu ukła­dan­ki w pro­jek­to­wa­niu roz­wią­zań, któ­ry jest nie­zwy­kle pomoc­ny w dostrze­ga­niu i prze­ka­zy­wa­niu ogól­ne­go obra­zu tych historyjek.”

Ronald Ross (Business Rules)

Źródła

Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agi­le requ­ire­ments: the Quality User Story fra­me­work and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
Ross, R. G., & Fisher, L. (2020). Business Rules: Management and Execution.
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 07881-6_15
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

Pełna Specyfikacja

Poniżej przy­kła­do­wy doku­ment wyge­ne­ro­wa­ny bez­po­śred­nio z Visual Paradigm, zawie­ra tak­że śladowanie. 

1. Procesy Business Process Diagram

Procesy Business Process Diagram

2. User Story

Historyjki użyt­kow­ni­ka jako wyma­ga­nia biznesowe.

ID

Nazwa

Rola

Produkt

Adresat

Opis

REQ001

Sprzedaż

Sprzedawca

Faktura

Klient

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

REQ002

Wydanie towa­ru

Magazynier

Dokument WZ

Klient

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

REQ003

Rejestracja Zamówień

Pracownik BOK

Zamówienie zaku­pu

Sprzedawca

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

REQ004

Śledzenie Zamówień

Klient

Zamówienie zaku­pu

Klient

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

3. Diagram Przypadków Użycia

Diagram Przypadków Użycia

4. Specyfikacja

 

Nazwa

ID

 

Główni akto­rzy 

Pula zadań

!!

Sprzedaż

UC02

Sprzedawca

Magazyny

UC03

Magazynier

Zamówienia

UC01

Klient, Pracownik BOK

4.1. Sprzedaż

ID: UC02

Usługa pozwa­la wysta­wiać faktury.

4.1.1. Główni aktorzy 

Sprzedawca

4.1.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Sprzedaż będzie doku­men­to­wa­na fak­tu­ra­mi w reje­strze sprzedaży

4.1.3. Wymagania 

4.1.3.1. Sprzedaż

ID: REQ001

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

4.1.4. Relacje

Relacja

Z

Do

unnamed

Sprzedawca

Sprzedaż

4.1.5. Diagramy Podległe 

4.1.5.1. Faktura

Faktura

4.1.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Sprzedaż

4.2. Magazyny

ID: UC03

Usługa doku­men­tu­je wyda­wa­nie towa­ru na pod­sta­wie opła­co­nych faktur.

4.2.1. Główni aktorzy 

Magazynier

4.2.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Operacje maga­zy­no­we doku­men­to­wa­ne są stan­dar­do­wy­mi doku­men­ta­mi księgowymi

4.2.3. Wymagania 

4.2.3.1. Wydanie towaru

ID: REQ002

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

4.2.4. Relacje

Relacja

Z

Do

unnamed

Magazynier

Magazyny

4.2.5. Diagramy Podległe 

4.2.5.1. Dokument WZ

Dokument WZ

4.2.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Wydanie z magazynu

4.3. Zamówienia

ID: UC01

Rejestr zamó­wień pozwa­la reje­stro­wać zamó­wie­nia, śle­dzić ich status.

4.3.1. Główni aktorzy 

Klient,  Pracownik BOK

4.3.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Zamówienia od klien­tów są reje­stro­wa­ne jako Zamówienia zaku­pu w Rejestrze zamówień

4.3.3. Wymagania 

4.3.3.1. Rejestracja Zamówień

ID: REQ003

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

4.3.3.2. Śledzenie Zamówień

ID: REQ004

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

4.3.4. Relacje

Relacja

Z

Do

unnamed

Pracownik BOK

Zamówienia

unnamed

Klient

Zamówienia

4.3.5. Diagramy Podległe 

4.3.5.1. Zamówienia Zakupu

Zamówienia Zakupu

4.3.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Rejestracja zamó­wie­nia

wymagania biznesowe

ocze­ki­wa­nia wobec roz­wią­za­nia, wyra­żo­ne języ­kiem natu­ral­nym z per­spek­ty­wy przy­szłe­go użyt­kow­ni­ka tego roz­wią­za­nia (przez nie­go); klu­czo­wą cechą tych wyma­gań są potrze­by wyra­żo­ne w fir­mie CO a nie JAK, chce osią­gnąć użytkownik.

Krótka historia pewnego wymagania

Wprowadzenie

Zarówno w pro­jek­tach jak i w dys­ku­sjach np. na kon­fe­ren­cjach czy na LinkedIn, poja­wia się sta­le pew­ne nie­po­ro­zu­mie­nie: pro­jek­to­wa­nie to water­fall”. Myśli tak każ­dy, kto wyobra­ża sobie, że pro­jekt cze­goś to jakaś masa wszyst­kich moż­li­wych deta­li. Jednocześnie nie ja jeden widu­ję Dokumenty ana­li­zy biz­ne­so­wej” albo Dokumenty wyma­gań” zawie­ra­ją­ce set­ki pozy­cji o tre­ści sys­tem powi­nien…”, nie raz wyko­na­ne przez kry­ty­ków water fall”, któ­rzy repre­zen­tu­jąc deve­lo­pe­ra dekla­ru­ją­ce­go meto­dy agi­le”, zabez­pie­cza­ją się” przez odpo­wie­dzial­no­ścią za zakres projektu. 

Pierwsza waż­na uwa­ga: pro­jekt sys­te­mu to nie jest ani zestaw dzie­siąt­ków user sto­ry” ani deta­licz­na doku­men­ta­cja powy­ko­naw­cza! I o tym dzi­siaj będzie: abs­tra­ho­wa­nie od deta­li i jed­nak nadal zarzą­dza­nie logi­ką całości.

Poniżej wyma­ga­nie napi­sa­ne przez dział IT jed­ne­go z moich klientów:

1. System musi posia­dać wbu­do­wa­ne­go klien­ta pocz­ty elek­tro­nicz­nej obsłu­gu­ją­ce­go co naj­mniej pro­to­ko­ły IMAP i SMTP.
2. Wbudowany klient pocz­ty elek­tro­nicz­nej posia­da nastę­pu­ją­ce funkcje:
2.1. Utwórz wia­do­mość ? umoż­li­wia utwo­rze­nie nowej wiadomości,
2.2. Odpowiedz ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.3. Odpowiedz wszyst­kim ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy oraz z prze­sła­niem jej na pozo­sta­łe adre­sy ema­il wymie­nio­ne w polu Do, Do wia­do­mo­ści oraz Ukryty do wia­do­mo­ści wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.4. Prześlij dalej ? umoż­li­wia prze­sła­nie pocz­ty elek­tro­nicz­nej kolej­ne­mu odbiorcy,
2.5. Przenieś ? umoż­li­wia prze­no­sze­nie pocz­ty elek­tro­nicz­nej pomię­dzy fol­de­ra­mi na wybra­nym koncie,
2.6. Drukuj ? umoż­li­wia wydru­ko­wa­nie pocz­ty elektronicznej,
2.7. Dołącz ? umoż­li­wia dołą­cze­nie pocz­ty elek­tro­nicz­nej do spra­wy lub dokumentu,
2.8. Odbierz ? umoż­li­wia ręcz­ne ode­bra­nie pocz­ty elektronicznej,
2.9. Usuń ? umoż­li­wia usu­nię­cie wybra­nej pocz­ty elektronicznej,
2.10. Znajdź ? umoż­li­wia wyszu­ka­nie listu w fol­de­rach pocz­ty elektronicznej,
2.11. Rejestruj ? umoż­li­wia reje­stra­cję pocz­ty elek­tro­nicz­nej jako doku­men­tu w sys­te­mie w spo­sób ana­lo­gicz­ny do reje­stra­cji doku­men­tu zeskanowanego.
3. System musi udo­stęp­niać moż­li­wość kon­fi­gu­ra­cji kon­ta pocz­ty elek­tro­nicz­nej każ­de­mu użytkownikowi.
4. System zapew­nia moż­li­wość kon­fi­gu­ra­cji wie­lu kont pocz­ty elek­tro­nicz­nej dla każ­de­go użytkownika.
5. System musi umoż­li­wiać reje­stra­cję (przej­mo­wa­nie) pocz­ty elek­tro­nicz­nej przez użyt­kow­ni­ka, lub poprzez zde­fi­nio­wa­ną regu­łę (uwzględ­nia­ją­cą zapi­sa­ne­go wcze­śniej adre­sa­ta, oraz cią­głość kore­spon­den­cji w spra­wie), jako doku­men­tów w sys­te­mie z podzia­łem na treść, załącz­ni­ki i nagłówek.
6. W celu ogra­ni­cze­nia zbęd­nej dupli­ka­cji, nie­prze­ję­te maile muszą być odczy­ty­wa­ne z ser­we­ra pocz­to­we­go tyl­ko na żąda­nie użyt­kow­ni­ka (dostęp­ny listing nagłów­ków wia­do­mo­ści) i nie powin­ny być dodat­ko­wo prze­cho­wy­wa­ne w Systemie.
7. Dotyczy to rów­nież pocz­ty wysy­ła­nej przez klienta.
8. System musi umoż­li­wiać dołą­cza­nie pocz­ty elek­tro­nicz­nej do doku­men­tów lub spraw. Dołączenie musi być moż­li­we z pozio­mu klien­ta pocz­ty elek­tro­nicz­nej wbu­do­wa­ne­go w system.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę A

Inna oso­ba z tego same­go dzia­łu dodała:

1. Chcemy mieć klien­ta pocz­to­we­go w sys­te­mie, jest to wygod­ne rozwiązanie.
2. Chcemy aby klient pocz­to­wy miał moż­li­wość odczy­ta­nia i wysła­nia wia­do­mo­ści pocztowej.
3. Nie chce­my żeby EOD gro­ma­dzi­ło wszyst­kie wia­do­mo­ści syn­chro­ni­zo­wa­ne z ser­we­rem pocz­to­wym pro­to­ko­łem IMAP, a tyl­ko pobie­ra­ło nagłów­ki wiadomości.
4. Gdy użyt­kow­nik uzna, że wia­do­mość jest czę­ścią spra­wy ini­cju­je czyn­no­ści w EOD.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę B.

Świadomie poda­je źró­dło: dział IT tej instytucji.

Opublikowałem tyl­ko powyż­sze, bo resz­ta po ano­ni­mi­za­cji i tak była by pustą kart­ką (nie­ste­ty ten OPZ uka­że się dopie­ro za jakiś czas, a do tego momen­tu jest pouf­ny), ale mam nadzie­ję, że wyobra­że­nie sobie resz­ty jest dość pro­ste. I co z tym? Nic! Otóż nie jest pro­ble­mem taka for­ma wyra­że­nia wyma­gań przez Zamawiającego, bo on (biz­nes i nie tyl­ko jak widać) ina­czej nie potra­fi i nie jest to jego rola. Problemem jest uzna­nie tego za wyma­ga­nia wobec opro­gra­mo­wa­nia”. Powyższe jest raczej dopie­ro mate­ria­łem do ana­li­zy i projektowania. 

Wyobraźmy sobie teraz hipo­te­tycz­ny doku­ment wyni­ko­wy, czy­li kil­ku­na­stu (a może nawet kil­ku­dzie­się­ciu) nie­tech­nicz­nych pra­cow­ni­ków tej insty­tu­cji (księ­go­wość, admi­ni­stra­cja, itp.) z pomo­cą ana­li­ty­ka wyma­gań”, zebra­ło wyma­ga­nia, i pra­cu­jąc z edy­to­rem tek­stu w try­bie reje­stra­cji zmian, warsz­ta­to­wo, po iluś tam tygo­dniach wypra­co­wa­ło” osta­tecz­ną wer­sję wyma­gań” a potem nawet dzie­siąt­ki user sto­ry”. Ile stron będzie mia­ła taka Analiza Biznesowa Wymagań i co w niej będzie? 

Przykłady łatwo zna­leźć w Internecie:

przy­kład 1 (źr. https://​zamo​wie​nia​.mazo​via​.pl/​?​a​c​t​=​i​n​f​o​&​i​d​=​1​2​001):

Powyższe opra­co­wa­nie kosz­to­wa­ło 90 tys. zł. 

przy­kład 2 (źr. https://​plat​for​ma​za​ku​po​wa​.pl/​t​r​a​n​s​a​k​c​j​a​/​3​6​1​167):

Rozwiązanie

Od cza­su do cza­su przy­wo­łu­je tu na blo­gu podej­ście zwa­ne Model jako wyma­ga­nie” (popu­lar­ne skró­ty to: MDD – Model Driven Development, MBSE – Model Based System Engineering, MDSE – Model Driven System Engineering, o MBSE już pisa­łem ).

Kluczem są mode­le struk­tur tre­ści (doku­men­tów i ekra­nów GUI) . Powyższe życze­nia” jako spi­sa­ne wyma­ga­nia to (w peł­nej wer­sji) ogrom­na lista życzeń, nie pod­da­ją­ca się żad­nej kon­tro­li spój­no­ści i kom­plet­no­ści. Proszę podej­rzeć wska­za­ne wyżej przy­kła­dy, doku­men­ty na ponad 200 stron nie pod­da­ją­ce się żad­nej kon­tro­li… (pomi­jam, że wadli­we for­mal­nie, jeśli cho­dzi o uży­cie deka­ro­wa­nej notacji). 

Poniżej zamien­nik wyłącz­nie powyż­sze­go o poczcie elek­tro­nicz­nej, wyra­żo­ny mode­lem struk­tu­ry tre­ści. Jaką ma to zale­tę? Tę, że mamy zamknię­tą struk­tu­rę tre­ści i może­my ją mapo­wać na inne doku­men­ty (ich sza­blo­ny w pro­jek­cie) w celi wery­fi­ka­cji logi­ki spójności. 

Zakresy danych nie reali­zu­ją­ce logi­ki biz­ne­so­wej (i mało ryzy­kow­ne jeśli cho­dzi o pra­co­chłon­ność) moż­na mar­ko­wać z dokład­no­ścią do roli dane­go zesta­wu danych (poni­żej obsza­ry ozna­czo­ne linia prze­ry­wa­ną). Zgodnie z defi­ni­cją, sys­te­my infor­ma­cyj­ne prze­twa­rza­ją dane, więc dowol­ny sys­tem infor­ma­cyj­ny jest spro­wa­dzal­ny do skoń­czo­nej licz­by infor­ma­cji wyra­ża­nej jako doku­ment gru­pu­ją­cy okre­ślo­ne dane i reguł ich prze­twa­rza­nia . Rzecz w tym, że nie jest to baza danych i rela­cyj­ny model” (nie­ste­ty mono­lit moż­li­wy do wypra­co­wa­nia meto­dą water­fall), a odręb­ne doku­men­ty i ich struk­tu­ry (oraz słow­ni­ki zna­czeń uży­tych nazw). Każdy z nich może być pod­sta­wą opra­co­wa­nia odręb­ne­go, moż­li­we­go do samo­dziel­ne­go wyko­na­nia, modułu. 

Warto wie­dzieć, że:

Model rela­cyj­ny danych: zapi­sy­wa­nie ich w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, jest pozba­wio­ny kon­tek­stu , nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokument, tak­że w sen­sie praw­nym, nie może być gene­ro­wa­ną dyna­micz­nie (zapy­ta­nia SQL do bazy rela­cyj­nej) struk­tu­rą, bo jest wte­dy wir­tu­al­nym bytem, a taki nie sta­no­wi doku­men­tu w pra­wie (Kodeks Cywilny), nie da się tak­że zarzą­dzać jego cyklem życia. Dlatego doku­men­ty są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD i uzu­peł­nia­ne posta­cią ??do czy­ta­nia i dru­ku? w for­ma­cie pdf (real­nie sa to pli­ki pdf z załą­czo­ny­mi wer­sja­mi XML. (źr. Informacje dla korzy­sta­ją­cych z moich opra­co­wań – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Poniżej pro­sty model listy ode­bra­nych maili”:

Wymagania doty­czą­ce pra­cy z pocz­ta elek­tro­nicz­ną obra­zu­je ten oto – wery­fi­ko­wal­ny – model struk­tu­ry tre­ści otrzy­ma­nej mailem:

Aby poka­zać jak to dzia­ła” pisze­my sce­na­riusz (spe­cy­fi­ka­cja przy­pad­ku uży­cia) sta­no­wią­cy kon­tekst uży­cia tego doku­men­tu (for­mu­la­rza). Służy on tak­że jako test pro­jek­to­wa­nej logi­ki, a póź­niej jako test odbior­czy goto­we­go produktu: 

1. Pracownik wybie­ra opcję Poczta Elektroniczna
2. SYSTEM wyświe­tla Lista prze­sy­łek ema­il dla zalo­go­wa­ne­go użytkownika
3. Pracownik kli­ka wybra­na pozy­cje na liście ,
4. SYSTEM wyświe­tla Treść Poczty Elektronicznej
5. Pracownik dekre­tu­je ją lub ozna­cza do usu­nię­cia OK
6. if dekretacja
6.1. wska­za­nie punk­tu kan­ce­la­ryj­ne­go i OK
7. else if usuń
end if 
8. SYSTEM sys­tem potwier­dza operacje

W tym momen­cie będę koń­czył, bo kon­ty­nu­ację czy­tel­nik znaj­dzie w jed­nym z wcze­śniej­szych arty­ku­łów, frag­ment poniżej: 

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up?y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD jest wystar­cza­ją­ca. Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wie­lo­krot­nie. (źr. Modele infor­ma­cyj­ne – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

Źródła

Šilingas, D., & Butleris, R. (2009). Towards imple­men­ting a fra­me­work for mode­ling softwa­re requ­ire­ments in MagicDraw UML. Information Technology and Control, 38(2).
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.

Analiza, wymagania i usprawnianie organizacji: MBSE

?Cechy wyróż­nia­ją­ce nowo­cze­sną teo­rię orga­ni­za­cji to jej poję­cio­wo-ana­li­tycz­na pod­sta­wa, jej opar­cie się na danych uzy­ski­wa­nych z badań empi­rycz­nych, ale przede wszyst­kim jej syn­te­ty­zu­ją­cy, inte­gra­cyj­ny cha­rak­ter. Te cechy wyróż­nia­ją­ce są zawar­te w filo­zo­fii, któ­ra akcep­tu­je zało­że­nie, że jedy­nym spo­so­bem bada­nia orga­ni­za­cji jest trak­to­wa­nie ich jako sys­te­mów? (Kostrzewski et al., 1979).

Wprowadzenie

Wbrew ocze­ki­wa­niom, tak zwa­ne zwin­ne meto­dy (agi­le mani­fe­sto, 2001 r.) nie popra­wi­ły jako­ści pro­jek­tów infor­ma­tycz­nych, nie raz zaś spo­wo­do­wa­ły wzrost kosz­tów i wydłu­ża­nie ter­mi­nów, a z uwa­gi na sys­tem roz­li­czeń czas i mate­riał”, nie pozwa­la­ją na pla­no­wa­nie budże­tu pro­jek­tu. Średnie i duże pro­jek­ty IT to nadal w ponad 80% poraż­ki .

Sprawdzają się jed­nak trud­niej­sze, ale znacz­nie sku­tecz­niej­sze, meto­dy zorien­to­wa­ne na mode­lo­wa­nie (ana­li­za sys­te­mo­wa i pro­jek­to­wa­nie) oraz rezy­gna­cja z mono­li­tycz­nej archi­tek­tu­ry sys­te­mów na rzecz archi­tek­tu­ry kom­po­nen­to­wej, wdra­ża­nej meto­da­mi ite­ra­cyj­no-przy­ro­sto­wy­mi . Metody te pozwo­li­ły na pro­jek­to­wa­nie roz­wią­zań infor­ma­tycz­nych i wdra­ża­nie ich w takt zmie­nia­ją­cych sie potrzeb. Pozwalają one tak­że na pla­no­wa­nie kosz­tów i ter­mi­nów już od począt­ku pro­jek­tu . Tak powsta­je tak zwa­na Specyfikacja SWS (Specyfikacja Wymagań Systemowych). 

Model Based Systems Engineering

Modelowanie pole­ga na abs­tra­ho­wa­niu od szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mecha­nizm .

MBSE to skrót od Model Based Systems Engineering (ang. inży­nie­ria sys­te­mów opar­ta na mode­lo­wa­niu) . System to nie tyl­ko sys­tem infor­ma­tycz­ny”, to tak­że cała orga­ni­za­cja, a nawet Państwo. 

Celem tego krót­kie­go arty­ku­łu jest poka­za­nie stan­dar­do­wej ścież­ki ana­li­zy sys­te­mo­wej i popra­wy orga­ni­za­cji, czy­li meto­dy pro­wa­dze­nia ana­li­zy sta­nu obec­ne­go i pro­jek­to­wa­nia roz­wią­zań, opar­tej na ana­li­zie fak­tów i mode­lo­wa­niu , któ­rych celem jest opra­co­wa­nie reko­men­da­cji do ulep­sze­nia orga­ni­za­cji . W 2008 roku OMG opu­bli­ko­wa­ło spe­cy­fi­ka­cję Software & Systems Process Engineering Metamodel (SPEM?), opi­su­ją­cą pro­ces prac nad budo­wą sys­te­mów, jed­nak wyglą­da na to, że pra­ce nad tą spe­cy­fi­ka­cją nie są kon­ty­nu­owa­ne. MBSE jako meto­da, wyda­je się być następ­cą tego pomy­słu (patrz: Survey of Model-Based Systems Engineering (MBSE) Methodologies) .

.

Podstawą pra­cy z mode­la­mi w ana­li­zie sys­te­mo­wej orga­ni­za­cji jest ide­ali­za­cja . Polega ona tym by w toku ana­li­zy i poszu­ki­wa­nia roz­wią­za­nia zapro­jek­to­wać ide­ał (model orga­ni­za­cji w wer­sji ide­al­nej), następ­nie opra­co­wa­niu stu­dium jego wyko­nal­no­ści, uzu­peł­nie­niu ide­ału o pozna­ne ogra­ni­cze­nia i wdro­że­nia tak zapro­jek­to­wa­ne­go sys­te­mu . Studium wyko­nal­no­ści ide­ału to ofer­ty dostaw­ców roz­wią­zań, któ­rych rola jest nie ana­li­za a opra­co­wa­nie kon­cep­cji wdrożenia. . 

Trzy poziomy modelowanie organizacji

Organizacje moż­na opi­sać na trzech klu­czo­wych poziomach:

Enterprise Level – (poziom orga­ni­za­cji) jest to poziom, na któ­rym opi­su­je się i mode­lu­je, stra­te­gie orga­ni­za­cji i jej rolę w oto­cze­niu ryn­ko­wym (ryn­ko­wy łań­cuch war­to­ści). Dotyczy to tak­że insty­tu­cji publicz­nych. Taki opis jako krót­ki doku­ment, jest czę­sto dostęp­ny na stro­nach WWW orga­ni­za­cji w zakład­ce O nas”, w pro­spek­tach emi­syj­nych, sta­tu­tach itp. Model powsta­je w toku for­ma­li­za­cji tego opisu. 

Business Process Level – to środ­ko­wy poziom, na któ­rym two­rzo­ny jest abs­trak­cyj­ny model orga­ni­za­cji w posta­ci tak zwa­ne­go wewnętrz­ne­go łań­cu­cha war­to­ści (pro­ces biz­ne­so­wy). Znakomita więk­szość orga­ni­za­cji nie ma takie­go doku­men­tu lub jest on nie­ak­tu­al­ny. Powodem tego sta­nu rze­czy jest to, że bie­żą­cej pra­cy ope­ra­cyj­nej jest on nie­po­trzeb­ny. Model taki przy­no­si jed­nak ogrom­ne korzy­ści w przy­pad­ku podej­mo­wa­niu decy­zji o zmia­nach. Jest to wte­dy pod­sta­wo­wy mate­riał obni­ża­ją­cy ryzy­ko wszel­kich decy­zji o jakich­kol­wiek zmia­nach orga­ni­za­cyj­nych lub pla­no­wa­nych wdrożeniach.

Implementation Level – to poziom opi­su­ją­cy szcze­gó­ły reali­zo­wa­nej pra­cy i wyko­rzy­sty­wa­nych narzę­dzi. To obszar tre­ści doku­men­tów takich jak: zakre­sy obo­wiąz­ków pra­cow­ni­ków i ich kom­pe­ten­cji, instruk­cje sta­no­wi­sko­we, pro­ce­du­ry, zarzą­dze­nia i regu­la­cje wewnętrz­ne, pod­ręcz­ni­ki uży­wa­nia sprzę­tu i opro­gra­mo­wa­nia oraz wie­le innych doku­men­tów o podob­nych cha­rak­te­rze. Dokumenty te są potrzeb­ne w bie­żą­cej pra­cy, jed­nak szyb­kie i sku­tecz­nie podej­mo­wa­nie decy­zji na ich pod­sta­wie ich tre­ści jest prak­tycz­nie nie­moż­li­we z uwa­gi na ich ilość i szczegółowość. 

Analiza biz­ne­so­wa pole­ga na audy­cie doku­men­tów ist­nie­ją­cych, czy­li tych z pozio­mu pierw­sze­go i trze­cie­go na powyż­szym dia­gra­mie, i opra­co­wa­niu na ich pod­sta­wie Modelu Procesów Biznesowych (środ­ko­wa war­stwa). Model ten to mecha­nizm funk­cjo­no­wa­nia orga­ni­za­cji, jej abs­trak­cyj­ny obraz, pozwa­la­ją­cy zapla­no­wać przy­szłe wdro­że­nie i prze­wi­dzieć jego efekty.

W toku ana­li­zy ma czę­sto miej­sce stan­da­ry­za­cja opi­su dzia­ła­nia i stra­te­gii. Jej celem jest for­ma­li­za­cja opi­su orga­ni­za­cji, bez cze­go nie jest moż­li­we doko­na­nie jakich­kol­wiek porów­nań np. z kon­ku­ren­cją, wyzna­cze­nie celów biz­ne­so­wych i wska­za­nie w orga­ni­za­cji miejsc mają­cych wpływ na te cele. 

Enterprise Level – Model biznesowy organizacji 

Strategia orga­ni­za­cji i jej rola w oto­cze­niu ryn­ko­wym są klu­czo­we dla zro­zu­mie­nia osią­ga­nych przez orga­ni­za­cję efek­tów. Mimo tego, że więk­szość orga­ni­za­cji dys­po­nu­je takim opi­sem, są one wyko­na­ne nie­for­mal­ny­mi meto­da­mi, tak róż­ny­mi, że jakie­kol­wiek porów­na­nie dwóch orga­ni­za­cji lub tej samej na prze­strze­ni lat jest prak­tycz­nie nie­moż­li­we. Dlatego opra­co­wa­no stan­dard zwa­ny Model Motywacji Biznesowej .

Standard ten sta­no­wi sobą pewien okre­ślo­ny sys­tem klu­czo­wych pojęć i związ­ków mię­dzy nimi. Jego celem jest stan­da­ry­za­cja pojęć takich jak: misja i wizja, stra­te­gia i tak­ty­ka, wewnętrz­ne i zewnętrz­ne czyn­ni­ki wpły­wu, cele i mier­ni­ki osią­ga­nia celu. 

Business Process Level – Model procesów biznesowych organizacji

Jest to model pozio­mu Business Process Level. To zna­czy, że nie ma tu miej­sca na szcze­gó­ły opi­sa­ne w doku­men­tach na pozio­mie Implementation Level. Model pro­ce­sów biz­ne­so­wych ma (powi­nien mieć) jedy­nie odno­śni­ki do szcze­gó­łów trze­ciej war­stwy, w szcze­gól­no­ści do pro­ce­dur, repre­zen­to­wa­nych na tym pozio­mie w posta­ci (abs­trak­cyj­nych) nazwa­nych aktywności.

Jednym z naj­bar­dziej zna­nych wzor­ców opi­su tego pozio­mu jest tak zwa­ny Wewnętrzny Łańcuch Wartości M. Portera, jest on nadal pod­sta­wo­wą wie­dzą każ­de­go absol­wen­ta stu­diów MBA. Model ten zakła­da podział pro­ce­sów na wspie­ra­ją­ce (admi­ni­stra­cja) i ope­ra­cyj­ne. Konkurencyjność i spraw­ność ope­ra­cyj­na ma dwa obsza­ry: w obsza­rze admi­ni­stra­cji, ści­śle regu­lo­wa­nym pra­wem, w zasa­dzie kon­ku­ru­je­my kosz­ta­mi, ale w obsza­rze ope­ra­cyj­nym, dają­cym znacz­nie więk­szą swo­bo­dę jego kształ­to­wa­nia, kon­ku­ren­cyj­ność to efekt spraw­no­ści orga­ni­za­cji, archi­tek­tu­ry pro­ce­sów biz­ne­so­wych i informacji. 

Łańcuch wartości M.E.Porter
Wewnętrzny łań­cuch wartości 

Z ww. powo­du w toku ana­li­zy i mode­lo­wa­nia sku­pia­my sie na obsza­rze ope­ra­cyj­nym, gdyż obszar wspar­cia admi­ni­stra­cyj­ne­go, z powo­du ści­słej zależ­no­ści od pra­wa, moż­na wes­przeć stan­dar­do­wym opro­gra­mo­wa­niem, łatwo dostęp­nym na ryn­ku. Ewentualne dedy­ko­wa­ne modu­ły są pro­jek­to­wa­ne wła­śnie dla obsza­ru ope­ra­cyj­ne­go, bo to tu wystę­pu­ją róż­ni­ce mię­dzy orga­ni­za­cja­mi i tu powsta­je prze­wa­ga kon­ku­ren­cyj­na (jeże­li doty­czy to orga­ni­za­cji kon­ku­ru­ją­cej na ryn­ku). Kluczem na tym eta­pie jest wska­za­nie miejsc do uspraw­nie­nia i opra­co­wa­nie roz­wią­za­nia. Próby kom­plek­so­we­go wdra­ża­na jed­ne­go sys­te­mu do wszyst­kie­go” naj­czę­ściej koń­czą się nie­ste­ty źle (kom­plek­so­we wdro­że­nia mono­li­tów ERPII mają bar­dzo złą reno­mę). Model Portera odno­si sie jed­na­ko­wym stop­niu do firm ryn­ko­wych jak i do insty­tu­cji publicznych. 

Więcej w arty­ku­le Analiza orga­ni­za­cji i opra­co­wa­nie Mapy Procesów.

Implementation Level – wdrożenie

Ten poziom i jego doku­men­ta­cja, to tak na praw­dę efekt pra­cy ope­ra­cyj­nej i pro­dukt wdro­że­nia norm jako­ści i pro­ce­dur, stra­te­gii zatrud­nie­nia, sys­te­mu infor­ma­tycz­ne­go itp. (patrz Operational Resources w poprzed­nim pod­roz­dzia­le). Tę doku­men­ta­cję two­rzą dostaw­cy roz­wią­zań oraz wewnętrz­ne służ­by admi­ni­stra­cji. Jako, że ona w róż­nych for­mach ist­nie­je w każ­dej fir­mie, sta­no­wi bazo­wy mate­riał źró­dło­wy w ana­li­zach sta­nu obec­ne­go. To dla­te­go ana­li­zę orga­ni­za­cji moż­na prze­pro­wa­dzić prak­tycz­nie w 100% bez kło­po­tli­wych i kosz­tow­nych spo­tkań warsz­ta­to­wych z pra­cow­ni­ka­mi ana­li­zo­wa­ne­go podmiotu. 

Rozwiązania informatyczne i wymagania

Niestety same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych to wyłącz­nie idea jego powsta­nia (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su, dają­cą ochro­nę w posta­ci peł­ne­go pra­wa do powsta­łe­go pro­duk­tu, uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt jego kon­struk­cji, struk­tur danych i mecha­ni­zmu dzia­ła­nia, sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we.

Obecne cza­sy to wszech­obec­na cyfry­za­cja. Dlatego zna­ko­mi­ta więk­szość roz­wią­zań wspie­ra­ją­cych dzia­ła­nia orga­ni­za­cji to sys­te­my infor­ma­cyj­ne wspie­ra­ją­ce pro­ce­sy biznesowe. 

Powyżej poka­za­no (zna­ny od lat 90-tych ubie­głe­go wie­ku) model archi­tek­tu­ry sys­te­mów infor­ma­cyj­nych zorien­to­wa­nej na usłu­gi apli­ka­cyj­ne. Pokazuje on związ­ki pomię­dzy pro­ce­sa­mi biz­ne­so­wy­mi a sys­te­ma­mi infor­ma­cyj­ny­mi, któ­rych doce­lo­wo w każ­dej orga­ni­za­cji jest wię­cej niż jeden. 

Systemy infor­ma­cyj­ne tak­że mode­lu­je­my na kil­ku poziomach: 

  1. Business Services – jako nazwa­ne usłu­gi biz­ne­so­we wyma­ga­ją­ce okre­ślo­nych usług apli­ka­cyj­nych, wspie­ra­ją­cych okre­ślo­ne aktyw­no­ści w pro­ce­sach, usłu­gi apli­ka­cyj­ne mode­lu­je­my jako przy­pad­ki uży­cia apli­ka­cji (są to wyma­ga­nia na rozwiązanie),
  2. Components – jako nazwa­ne i wyspe­cy­fi­ko­wa­ne kom­po­nen­ty apli­ka­cyj­ne wraz z ich inte­gra­cją (jest to opis rozwiązania),
  3. Operational Resources – jako model opi­su­ją­cy fak­tycz­ne ich wdro­że­nie i roz­lo­ko­wa­nie (jest to doku­men­ta­cja wdro­żo­ne­go systemu). 

Kluczowymi sto­so­wa­ny­mi stan­dar­da­mi nota­cyj­ny­mi są tu BPMN, UML, SBVR . Więcej w arty­ku­le Analiza i opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie.

Opracowanie spe­cy­fi­ka­cji wyma­gań (mode­li) nie powin­no nigdy w obec­nych cza­sach trwać dłu­żej niż kwar­tał, co ozna­cza, że im więk­szy pro­jekt tym bar­dziej spe­cy­fi­ka­cja wyma­gań jest poli­ty­ką (archi­tek­tu­rą) niż deta­licz­nym opi­sem. Detale są spe­cy­fi­ko­wa­ne już w toku wdro­że­nia w toku nad­zo­ru autor­skie­go, zgo­dzie z poli­ty­ką budo­wy i wdra­ża­nia sys­te­mu (archi­tek­tu­rą). Wycena reali­za­cji nie powin­na spra­wić kło­po­tu, żad­nej doświad­czo­nej, zna­ją­cej wzor­ce archi­tek­to­nicz­ne, fir­mie ofru­ją­cej oprogramowanie. 

Praca z dostawcami rozwiązań

Praktycznie zawsze pada pyta­nie: a co jeże­li dostaw­ca też robi ana­li­zę przed­wdro­że­nio­wą? Otóż tu już jej nie robi bo ją dosta­je. Z uwa­gi na ryzy­ko pro­jek­tu i poten­cjal­ny kon­flikt inte­re­su, Dostawca z zasa­dy nie powi­nien być auto­rem wyma­gań (pro­jek­tu rozwiązania). 

Dostawca musi opra­co­wać pro­po­no­wa­ną przez sie­bie Koncepcję Wdrożenia ofe­ro­wa­ne­go pro­duk­tu, w odpo­wie­dzi na wyma­ga­nia wyra­żo­ne w posta­ci mode­li pro­ce­sów biz­ne­so­wych, struk­tur doku­men­tów i reguł biz­ne­so­wych (Model Biznesowy Organizacji). Z uwa­gi na to, że pro­jek­ty takie zawsze reali­zo­wa­ne są meto­dą ite­ra­cy­no-przy­ro­sto­wą, w toku pro­jek­tu ma miej­sce sta­ła współ­pra­ca: Dostawca roz­wią­za­nia żąda kolej­nych deta­licz­nych infor­ma­cji o tym jak dzia­ła fir­ma Zamawiającego, Zamawiający, z moją pomo­cą (nad­zór autor­ski), odpo­wia­da odsy­ła­jąc sta­le uzu­peł­nia­ny Model Biznesowy. Dostawca doku­men­tu­je kolej­ne eta­py pro­wa­dzo­ne­go wdro­że­nia (aktu­ali­zu­je Koncepcję Wdrożenia, któ­ra sta­je się doku­men­ta­cją tego wdro­że­nia) a ja je (te doku­men­ty) wery­fi­ku­ję, i tak aż do zakoń­cze­nia wdrożenia. 

Na koniec wdro­że­nia Zamawiający dys­po­nu­je dwo­ma aktu­al­ny­mi doku­men­ta­mi: Model Biznesowy (środ­ko­wa war­stwa opi­su orga­ni­za­cji) i Dokumentacja Wdrożenia (opi­sa­ny wyżej Poziom Implementacji).

Podsumowanie

Każdy pro­jekt zwią­za­ny z reor­ga­ni­za­cją i/lub wdra­ża­niem nowe­go opro­gra­mo­wa­nia (zmian, roz­bu­do­wy) moż­na więc prze­pro­wa­dzić meto­dą ana­li­zy orga­ni­za­cji i jej mode­lo­wa­nia na z góry usta­lo­nym pozio­mie szcze­gó­ło­wo­ści. Modele te są ści­śle zin­te­gro­wa­ne z sobą, a całość ma cha­rak­ter opi­su od ogó­łu do szczegółu”. 

Podejście to gwa­ran­tu­je spój­ność, kom­plet­no­ści i nie­sprzecz­ność opi­su na każ­dym eta­pie pro­jek­tu. Dzięki temu mini­ma­li­zu­je­my ryzy­ko nie­uda­ne­go wdro­że­nia a całość trwa krót­ko (żaden etap ana­li­zy nie powi­nien trwać dłu­żej niż kwar­tał!). Prosty ale obra­zo­wy przy­kład opi­sa­łem TUTAJ.

Całość lite­ra­tu­ra przed­mio­tu opi­su­je od wie­lu lat, meto­dy te są sta­le dosko­na­lo­ne. Poniżej pro­ces two­rze­nia opro­gra­mo­wa­nia jako pro­jek­to­wa­nie systemu: 

Model sys­te­mu jest celem ana­li­zy opar­tej o przy­pad­ki uży­cia (wywo­dzo­ne z pro­ce­sów biz­ne­so­wych) i ich sce­na­riu­sze, na ich pod­sta­wie powsta­je model sys­te­mu, kolej­ny krok to imple­men­ta­cja (code) jed­nak nadal dłu­go jesz­cze będzie to pra­ca dla deve­lo­pe­rów .

Przypadki uży­cia (use case) to wynik opi­sa­nej na począt­ku ana­li­zy biz­ne­so­wej (orga­ni­za­cja to tak­że sys­tem) i wyod­ręb­nie­nia celów biz­ne­so­wych. Mamy rok 2021 i ogrom­ny wybór dostęp­ne­go, goto­we­go opro­gra­mo­wa­nia wyma­ga­ją­ce­go jedy­nie wła­ści­we­go dobo­ru i inte­gra­cji. Tak opi­sa­ny wyżej sys­tem to struk­tu­ra i zacho­wa­nie się dobra­nych kom­po­nen­tów, nie koniecz­nie jest to pisa­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia od zera”, bo to ma miej­sce coraz rza­dziej i doty­czy ewen­tu­al­nie 10 – 15% dedy­ko­wa­nych potrzeb nie­któ­rych firm. 

Obecne na ryn­ku sys­te­my wspie­ra­ją­ce ana­li­zy i pro­jek­to­wa­nie (CASE: Computer Aided System Engineering) oraz wzor­ce archi­tek­to­nicz­ne i narzę­dzia infor­ma­tycz­ne, pozwa­la­ją pro­wa­dzić ana­li­zy i mode­lo­wa­nie eta­pa­mi trwa­ją­cy­mi poje­dyn­cze tygo­dnie a nie lata. Iteracyjno-przy­ro­stwe meto­dy dostar­cza­nia opro­gra­mo­wa­nia pozwa­la­ją wdra­żać nowo­cze­sne roz­wią­za­nia w okre­sach kwar­tal­nych a nie lat. 

Poniżej pro­sty przy­kład pro­duk­tu takiej pracy:

[down­lo­ad id=„28199”]

Sprawdź aktu­al­ne kosz­ty takie­go pro­jek­tu: KOSZT.

Źródła

Sienkiewicz, P. (1994). Analiza sys­te­mo­wa: pod­sta­wy i zasto­so­wa­nia. Wydaw. Bellona.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2015, April). Business Motivation Model (BMM). https://​www​.omg​.org/​s​p​e​c​/​B​MM/
Estefan, J. A. (2007). Survey of Model-Based Systems Engineering (MBSE) Methodologies. 47.
Harel, D. (2000). From play-in sce­na­rios to code: An achie­va­ble dre­am. International Conference on Fundamental Approaches to Software Engineering, 22 – 34.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
BPTrends Associates. (2020). BPTrends Associates | BPM ana­ly­sis, opi­nion and insi­ght. http://​www​.bptrend​sas​so​cia​tes​.com/
Suri, K., Cuccuru, A., Cadavid, J., Gerard, S., Gaaloul, W., & Tata, S. (2017). Model-based Development of Modular Complex Systems for Accomplishing System Integration for Industry 4.0: Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development, 487 – 495. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​6​2​1​0​5​0​4​8​7​0​495
Jones, S. (2006). Enterprise SOA adop­tion stra­te­gies: using SOA to deli­ver IT to the busi­ness. C4Media.
Koźmiński, A. K. (1979). Decyzje: ana­ly­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Jenney, J., Gangl, M., Kwolek, R., Melton, D., Ridenour, N., & Coe, M. (2010). Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Joe Jenney.
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.

Wymagania umarły. Rozwiązaniem jest cykl życia produktu

Jak to mawiał mój daw­ny pro­fe­sor filo­zo­fii: gdy dwóch mówi to samo to już nie jest samo”. To co nazy­wa­my zwin­nym podej­ściem” to coraz czę­ściej uzna­nie nie­sku­tecz­no­ści meto­dy pole­ga­ją­cej na zbie­ra­niu wyma­gań” i obro­na przed obie­ca­niem z góry tego co ma powstać”, bo nikt nie wie czym to coś będzie jak już powstanie…(o ile powsta­nie). Takie gło­sy poja­wia­ją się coraz czę­ściej, i to nie od wczoraj.…

Dzisiaj metody oparte na abstrakcji

Takie pomy­sły” jak MDA (archi­tek­tu­ra bazu­ją­ca na mode­lo­wa­niu), MDE (inży­nie­ria bazu­ją­ca na mode­lo­wa­niu), nota­cje BPMN, UML, SysML, SoaML i podob­ne, sta­no­wią­ce sobą for­mę rysun­ku tech­nicz­ne­go na wyso­kim pozio­mie abs­trak­cji, to ścież­ka nie raz ratu­ją­ca pro­jek­ty infor­ma­tycz­ne. To meto­da pozwa­la­ją­ca radzić sobie z rosną­cą zło­żo­no­ścią inży­nie­rii jako cało­ści. Te narzę­dzia powsta­ją i są roz­wi­ja­ne od ponad 20 lat… Konstrukcji dzi­siej­sze­go tram­wa­ju czy zło­żo­ne­go opro­gra­mo­wa­nia, nie da sie już rze­tel­nie i pre­cy­zyj­nie opi­sać z pomo­cą listy wyma­gań zebra­nych w trak­cie spo­tkań warsz­ta­to­wych” na roz­sąd­nej ilo­ści stron papie­ru. Ich podział na funk­cjo­nal­ne i poza funk­cjo­nal­ne” nie wpro­wa­dza nicze­go nowe­go do takiej listy. Ta tech­ni­ka spe­cy­fi­ko­wa­nia (IEEExxx-1998?1?) ma swo­je począt­ki ponad 30 lat temu!

W czym problem?

Niedawno uka­zał się kolej­ny cie­ka­wy arty­kuł na ten temat.

Requirements gathe­ring is one phra­se I have lear­ned not to use with sta­ke­hol­ders as I deli­ver pro­jects. It appe­ars to have struck fear, cyni­cism and/or anxie­ty in many of the user gro­ups I have to enga­ge at the most impor­tant sta­ge of the solu­tion ? the begin­ning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution2

Popularne sło­wo eli­ci­ta­tion” to uzy­ski­wa­nie, wydo­by­wa­nie”. Branża IT poszła w kie­run­ku uzna­nia, że zain­te­re­so­wa­ny (sta­ke­hol­der) ma rozu­mieć wyma­ga­nia”. To jed­nak nie działa.

Elicitation And Other Animals The indu­stry then moved on with the ter­mi­no­lo­gy, to use the term ?eli­ci­ta­tion.? To add com­ple­xi­ty, the­re were sepa­ra­te defi­ni­tions of func­tio­nal requ­ire­ments, being dif­fe­rent to busi­ness requ­ire­ments, then get­ting tech­ni­cal and coming up with sys­tem requ­ire­ments. All of the types of requ­ire­ments have clo­uded the under­stan­ding by sta­ke­hol­ders, and then time is lost in the defi­ning the ter­mi­no­lo­gy befo­re any discus­sions have begun. A ple­tho­ra of whi­te papers and autho­red artic­le can descri­be the dif­fe­ren­ces and it?s abso­lu­te­ly cle­ar in some of tho­se eso­te­ric minds.. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution2).

Nie wol­no zapo­mi­nać, że zama­wia­ją­cy nie jest inży­nie­rem. To co potra­fi powie­dzieć zama­wia­ją­cy i to co jest w sta­nie zro­zu­mieć to wyłącz­nie wyma­ga­nia biz­ne­so­we” i nic ponad to. Poprzestanie w pro­jek­cie na takich wyma­ga­niach” nie sta­no­wi żad­nych wyma­gań wobec inży­nier­skiej kon­struk­cji jaką ma wyko­nać deve­lo­per (czy­li inży­nier). Nie nale­ży tak­że zapo­mi­nać o tym, że każ­dy biz­ne­so­wy udzia­ło­wiec” ma swój inte­res” do reali­za­cji, wyma­ga­nia biz­ne­so­we to nic inne­go jak cele tych ludzi. I teraz klu­czo­we pyta­nie: kogo pytać o wyma­ga­nia np. dla opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go sprze­daż: pre­ze­sa tej fir­my czy jego sprze­daw­ców wal­czą­cych o pro­wi­zje mają­cych nadzie­ję, że ktoś zło­ży im pro­po­zy­cję lepiej płat­nej pra­cy? Sponsorem pro­jek­tów są zarzą­dy firm, ocze­ku­ją ter­mi­nów, nazw, opi­sów a nie nadziei…

Today?s pro­ject needs are for solu­tions measu­red in time-to-mar­ket, risk reduc­tion, take-up rates, or bet­ter still, what you defi­ned as measu­ra­ble at the begin­ning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution2

Powiązany arty­kuł zawie­ra inne cie­ka­we pytanie: 

Czego ocze­ku­je biz­nes: efek­tu czy produktu?

What Is The Difference Between Outcome And Output? Before I go much fur­ther, I sho­uld pro­ba­bly expla­in what I mean when I use the words out­co­me and out­put in a con­text rele­vant to busi­ness ana­ly­sts:
- Outcome is the chan­ge in the orga­ni­za­tion and chan­ges in the beha­vior of sta­ke­hol­ders as a result of a pro­ject.
- Output is any­thing that your team deli­vers as part of your pro­ject. This could inc­lu­de requ­ire­ments, docu­men­ta­tion, pro­ces­ses, softwa­re, tests and other things that tend to be measu­red in order to gau­ge how the pro­ject is going.
(Źródło: Business Analyst | Your Job Is Not to Elicit and Document Requirements3

i tu poja­wia się teza dla analityków:

Requirements Are (Not The Final) Output (wyma­ga­nia nie są osta­tecz­nym pro­duk­tem analityka)

To co nim jest? Popatrzmy na pro­ces tak zwa­nej ana­li­zy systemowej:

Gdzie jest faza zbie­ra­nia wyma­gań” w rozu­mie­niu eli­ci­ta­tion”? W zasa­dzie jest to dopie­ro począ­tek dro­gi czy­li sfor­mu­ło­wa­nie pro­ble­mu. Następnie ktoś powi­nien zba­dać śro­do­wi­sko pro­ble­mo­we czy­li prze­pro­wa­dzić bada­nie (ana­li­za biz­ne­so­wa orga­ni­za­cji) i opra­co­wać model (mapy pro­ce­sów biz­ne­so­wych, struk­tu­ry infor­ma­cyj­ne). Kolejny krok to inter­pre­ta­cja wyni­ków bada­nia. Co jest tą reko­men­da­cją? Jest nią reko­men­do­wa­ne roz­wią­za­nie pro­ble­mu, tym roz­wią­za­niem może być opro­gra­mo­wa­nie, zmia­ny orga­ni­za­cyj­ne a naj­czę­ściej jed­no i drugie.

Jednak nie jest roz­wią­za­niem stwier­dze­nie: powin­ni­ście sobie kupić jakieś opro­gra­mo­wa­nie i popra­wić orga­ni­za­cję”. Rozwiązaniem (reko­men­da­cją) jest raczej: to jest struk­tu­ra i logi­ka dzia­ła­nia opro­gra­mo­wa­nia, któ­re reko­men­du­ję a to są reko­men­do­wa­ne zmia­ny organizacyjne”. 

I to dopie­ro jest naj­wcze­śniej­szy moment na wpusz­cze­nie” developera.

Nikogo w biz­ne­sie nie inte­re­su­je tak na praw­dę suchy spis pro­ble­mów (wyma­ga­nia zebra­ne na warsz­ta­tach wśród pra­cow­ni­ków), biz­nes jest zain­te­re­so­wa­ny czymś co moż­na nazwać, kupić i wdro­żyć w okre­ślo­nym cza­sie bo tyl­ko to pozwa­la na osza­co­wa­nie korzy­ści z takiej inwestycji.

Rynek zmie­nia się szyb­ko, więc nie ma sen­su szcze­gó­ło­we pro­jek­to­wa­nie cze­go­kol­wiek z uwa­gi na czas jaki zaj­mie takie pro­jek­to­wa­nie i ryzy­ko, że taki pro­jekt sta­nie się szyb­ko nie­ak­tu­al­ny. Nikt roz­sąd­ny nie nama­wia dzi­siaj do cze­goś o wdzięcz­nej nazwie water­fall”. Co więc zro­bić? Dla dużych pro­jek­tów two­rzy­my archi­tek­tu­rę, opi­su­je­my mecha­ni­zmy dzia­ła­nia, poli­ty­kę roz­bu­do­wy i opis cyklu życia. Czyli to co pozwo­li roz­wi­jać roz­wią­za­nie meto­dą ite­ra­cyj­no-przy­ro­sto­wą, w razie potrze­by pozwo­li na prze­pro­jek­to­wa­nie, ale jako całość nadal będzie spój­ne, nie będzie wyma­ga­ło wymia­ny cało­ści gdy zmie­nią się warun­ki na rynku.

Można w tym miej­scu zary­zy­ko­wać tezę, że nie ma cze­goś takie­go jak inży­nie­ria wyma­gań” bo czym ona jest i co jest jej pro­duk­tem? Uporządkowany spis życzeń? Mamy nato­miast na pew­no inży­nie­rię sys­te­mów”.… sys­te­ma­mi są orga­ni­za­cje a tak­że narzę­dzia jakich uży­wa­ją np. oprogramowanie…

________________________________
  1. 1.
    Żeliński J. IEEE1998 Czy pro­du­ku­je dobre wyma­ga­nia. IT​-Consulting​.pl. https://it-consulting.pl//2008/09/27/ieee830-1998-%e2%80%93-czy-produkuje-dobre-wymagania/. Published March 9, 2017. Accessed December 24, 2018.
  2. 2.
  3. 3.

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten arty­kuł moż­na czy­tać na dwa spo­so­by: ana­li­ty­cy czy­ta­ją od dechy do dechy po kolei ;). Menedżerowie i tak zwa­ny biz­nes czy­ta­ją od razu koniec, to jest część Na zakoń­cze­nie, gdy uzna­ją, że nie wie­rzą w te wnio­ski (wyrok) to zaczy­na­ją od począt­ku czy­li czy­ta­ją uzasadnienie :).

Niedawno napi­sa­łem:

Pomiędzy poję­cia­mi abs­trak­cja i model jest pew­na klu­czo­wa róż­ni­ca: abs­trak­cja to poję­cie zaś model to opis mecha­ni­zmu, jego kon­struk­cja, dzia­ła­nie, budo­wa. Prosty przy­kład: nazwa­ne pro­sto­ką­ty na typo­wym dia­gra­mie struk­tu­ry orga­ni­za­cyj­nej to abs­trak­cje komó­rek orga­ni­za­cyj­nych i osób w nich zatrud­nio­nych, pro­sto­ką­ty te wraz z linia­mi je łączą­cy­mi sta­no­wią, jako całość, model pod­le­gło­ści zaso­bów w orga­ni­za­cji. (Źródło: Analiza a mode­lo­wa­nie czy­li ile abs­trak­cji a ile rze­czy­wi­sto­ści | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej per­spek­ty­wy powie­my sobie teraz o eta­pach ana­li­zy i pro­jek­to­wa­nia w inży­nie­rii, nie tyl­ko opro­gra­mo­wa­nia, w opar­ciu o MDA ([[Model Driven Architecture]], www​.omg​.org/​mda, pole­cam tak­że poję­cie [[model dri­ven engi­ne­ering]]). Dobra infor­ma­cja dla czy­tel­ni­ków: na koń­cu się wszyst­ko wyja­śni, moż­na pomi­nąć część o MDA 🙂

MDA

Pięć lat temu, jeden z arty­ku­łów o mode­lo­wa­niu i pro­jek­to­wa­niu, koń­czy­łem tymi słowami:

Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

  1. Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (model biz­ne­so­wy) oraz opis tego co ma powstać (opis, wyma­ga­nia na opro­gra­mo­wa­nie). Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
  2. Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: opra­co­wa­niu szcze­gó­łów archi­tek­tu­ry, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne), kodo­wa­niu oraz dostar­cze­niu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biz­ne­su czy­li dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tek­ście wła­śnie na MDA. Czymże to jest? Na stro­nach OMG znaj­dzie­my: Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revi­sed MDA Guide edi­ted in Boston on 18 June 2014 reflects all AB edits requ­ested at the Reston and Boston AB meetings. (Źródło: OMG Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0)

Skorzystam z kil­ku cyta­tów i napi­sze co nie­co o MDA. Poniżej klu­czo­we tezy, nie mia­łem tu ambi­cji lite­ral­ne­go tłu­ma­cze­nia tego doku­men­tu, cho­dzi­ło mi o pryncypia.

This guide descri­bes the Model Driven Architecture (MDA) appro­ach as defi­ned by the Object Management Group (OMG). MDA pro­vi­des an appro­ach for deri­ving value from models and archi­tec­tu­re in sup­port of the full life cyc­le of phy­si­cal, orga­ni­za­tio­nal and I.T. sys­tems (A ?System?, in this con­text, is any arran­ge­ment of parts and the­ir inter­re­la­tion­ships, wor­king toge­ther as a who­le.). The MDA appro­ach repre­sents and sup­ports eve­ry­thing from requ­ire­ments to busi­ness mode­ling to tech­no­lo­gy imple­men­ta­tions. By using MDA models, we are able to bet­ter deal with the com­ple­xi­ty of lar­ge sys­tems and the inte­rac­tion and col­la­bo­ra­tion betwe­en orga­ni­za­tions, people, har­dwa­re, software.

Stosowanie mode­li pozwa­la znacz­nie lepiej radzić sobie ze zło­żo­no­ścią wiel­kich sys­te­mów jaki­mi są orga­ni­za­cje oraz funk­cjo­nu­ją­ce w nich związ­ki mię­dzy ludź­mi, opro­gra­mo­wa­niem i infra­struk­tu­rą. Fakt, że bada­ne orga­ni­za­cje współ­pra­cu­ją z inny­mi, dodat­ko­wo kom­pli­ku­je tę całość.

Models as com­mu­ni­ca­tions vehicles

A fun­da­men­tal value pro­po­si­tion for models and mode­ling is to faci­li­ta­te a team or com­mu­ni­ty coming to a com­mon under­stan­ding and/or consensus.

Jedną z głów­nych ról mode­li, poza ich ana­li­zą, jest komu­ni­ka­cja: komu­ni­ku­je­my innym człon­kom zespo­łu (tak­że klien­tom) to co zro­zu­mie­li­śmy i to cze­go ocze­ku­je­my. Tak więc mode­le są zarów­no opi­sem rze­czy­wi­sto­ści powsta­łym w toku jej zro­zu­mie­nia, są tak­że opi­sem tego co ma powstać, jeże­li chce­my tę rze­czy­wi­stość stworzyć.

[?]Abstraction deals with the con­cepts of under­stan­ding a sys­tem in a more gene­ral way; said in more ope­ra­tio­nal terms, with abs­trac­tion one eli­mi­na­tes cer­ta­in ele­ments from the defi­ned sco­pe; this may result in intro­du­cing a higher level view­po­int at the expen­se of remo­ving deta­il. A model is con­si­de­red more abs­tract if it encom­pas­ses a bro­ader set of sys­tems and less abs­tract if it is more spe­ci­fic to a sin­gle sys­tem or restric­ted set of systems. [?]

Podstawową rze­czą w ana­li­zie jest redu­ko­wa­nie szcze­gó­łów i uogól­nia­nie. Człowiek nie jest w sta­nie ana­li­zo­wać cze­goś co skła­da się z setek detali.

Model Analytics

Once models are cap­tu­red as seman­tic data vario­us ana­ly­tics can be exe­cu­ted across tho­se models inc­lu­ding model vali­da­tion, sta­ti­stics and metrics. Analytics assi­sts in deci­sion making, moni­to­ring and quali­ty asses­sment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele poję­cio­we i ana­li­tycz­ne słu­żą do zro­zu­mie­nia bada­nej rze­czy­wi­sto­ści. Modele two­rzo­ne (pro­jek­to­wa­nie) słu­żą do testo­wa­nia pomy­słów i podej­mo­wa­nia decy­zji, dalej zaś sta­no­wią opis cech wyma­ga­ne­go roz­wią­za­nia. Modele wyko­ny­wal­ne to inne mode­le ale bazu­ją na mode­lach ana­li­tycz­nych. Poniżej, na bazie MOF ([[Meta Object Facility]]), poka­za­no trzy pozio­my abs­trak­cji (poziom zero­wy to rzeczywistość).

poziomy-abstrakcji

Abstrakcja to uprosz­czo­ny” (pozba­wio­ny zbęd­nych szcze­gó­łów) model okre­ślo­nej rze­czy­wi­sto­ści. Metamodel to mecha­nizm two­rze­nia tej rze­czy­wi­sto­ści w tym tak­że model poję­cio­wy (wię­cej w dal­szej części).

Model (M1) więc jest albo wyni­kiem (pro­duk­tem) ana­li­zy bada­nej rze­czy­wi­sto­ści, albo wyni­kiem (pro­duk­tem) pro­ce­su jej pro­jek­to­wa­nia (pro­jek­to­wa­nia rozwiązania). 

Model Simulation and Execution

Models as data can dri­ve simu­la­tion engi­nes that can assist in both ana­ly­tics and exe­cu­tion of the desi­gns cap­tu­red in models. Simulation assi­sts in the human under­stan­ding of how a mode­led sys­tem will func­tion as well as a way to vali­da­te that models are cor­rect. Models can, in some cases be direc­tly exe­cu­ted ? serving as the ?sour­ce code? for high­le­vel appli­ca­tions that imple­ment pro­ces­ses, data repo­si­to­ries and servi­ce end­po­ints. Model exe­cu­tion pro­vi­des a direct and imme­dia­te path to reali­zing a design with a mini­mum of tech­ni­cal deta­ils being expo­sed. DBMS Schema and pro­cess models are well-known cate­go­ries of (par­tial­ly) exe­cu­ta­ble models.[?]

Modele symu­la­cyj­ne słu­żą do testo­wa­nia hipo­tez i podej­mo­wa­ni decy­zji. Modele wyko­ny­wal­ne, w tym two­rzo­ne auto­ma­tycz­nie na bazie mode­li abs­trak­cyj­nych, to narzę­dzia do two­rze­nia wyko­ny­wal­ne­go kodu. Nie tyl­ko w moim mnie­ma­niu, jest to albo dale­ka przy­szłość (mam na myśli komer­cyj­ne zasto­so­wa­nia) albo wyłącz­nie aka­de­mic­kie bada­nia. Wiem, że są uda­ne pró­by gene­ro­wa­nia dzia­ła­ją­ce­go kodu z mode­li, jed­nak wyma­ga­nia na ilość deta­li, jakie trze­ba zade­kla­ro­wać w tych mode­lach, zbli­ża ich zło­żo­ność do zło­żo­no­ści kodu jaki powsta­je. Nie będzie­my się tu zaj­mo­wa­li mode­la­mi wykonywalnymi.

Cztery produkty

Te dwa opi­sa­ne na począt­ku eta­py do ana­li­za sys­te­mo­wa orga­ni­za­cji (potocz­nie ana­li­za biz­ne­so­wa”) oraz imple­men­ta­cja roz­wią­za­nia. Produkty to …

MDA to archi­tek­tu­ra mają­ca trzy pozio­my mode­lo­wa­nia, nazy­wa­ne od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is use­ful to iden­ti­fy par­ti­cu­lar ?lay­ers? of an archi­tec­tu­re with respect to its level of abs­trac­tion. While the­re can be any num­ber of archi­tec­tu­ral lay­ers, a bro­ad cate­go­ri­za­tion of this con­cept is:

  • Business or doma­in models ? models of the actu­al people, pla­ces, things, and laws of a doma­in. The ?instan­ces? of the­se models are ?real things?, not repre­sen­ta­tions of tho­se things in an infor­ma­tion sys­tem. In MDA doma­in models have histo­ri­cal­ly been cal­led a ?CIM? for ?Computation Independent Model?.
  • Logical sys­tem models ? models of the way the com­po­nents of a sys­tem inte­ract with each other, with people and with orga­ni­za­tions to assist an orga­ni­za­tion or com­mu­ni­ty in achie­ving its goals. [model PIM]
  • Implementation models ? the way in which a par­ti­cu­lar sys­tem or sub­sys­tem is imple­men­ted such that it car­ries out its func­tions. Implementation models are typi­cal­ly tied to a par­ti­cu­lar imple­men­ta­tion tech­no­lo­gy or plat­form. [model PSM].

Model CIM opi­su­je ludzi i ich związ­ki, miej­sca, pra­wa rzą­dzą­ce tym wszyst­kim. Ten model opi­su­je real­ną, bada­ną rze­czy­wi­stość cał­ko­wi­cie abs­tra­hu­jąc od wyko­rzy­sty­wa­nych ewen­tu­al­nie posia­da­nych narzę­dzi infor­ma­tycz­nych (w przy­pad­ku start-up’u lub roz­wo­ju orga­ni­za­cji jest to przy­szła jej postać). Nie jest to model jakie­go­kol­wiek opro­gra­mo­wa­nia ani tego jak ono dzia­ła. Produktem tego eta­pu są: mode­le pro­ce­sów biz­ne­so­wych, spe­cy­fi­ka­cja reguł biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć i mode­le pojęciowe.

Model PIM opi­su­je kom­po­nen­ty apli­ka­cji, ich wza­jem­ne inte­rak­cje, logi­kę dzia­ła­nia tych kom­po­nen­tów (ta część logi­ki opi­sa­nej w mode­lu CIM, któ­ra ma być reali­zo­wa­na w apli­ka­cji). Produktem tego eta­pu są mode­le: przy­pad­ków uży­cia (w tym postać nośni­ków danych, moc­ku­p’y ekra­nów), kom­po­nen­tów, wewnętrz­ne struk­tu­ry kom­po­nen­tów (mode­le dzie­dzi­ny z per­spek­ty­wy wzor­ca MVC), inte­rak­cji, inne jeśli konieczne.

Model PSM to model będą­cy pro­jek­tem wyko­naw­czym. Jest to roz­sze­rze­nie mode­lu PIM, uszcze­gó­ło­wie­nie go wraz z dodat­ko­wy­mi ele­men­ta­mi tech­nicz­ny­mi (reali­zu­ją­cy­mi śro­do­wi­sko, bez­pie­czeń­stwo, wyma­ga­ną wydaj­ność itp.). Kod apli­ka­cji to mate­ria­li­za­cja (imple­men­ta­cja) mode­lu PSM. 

Powyższe, to czte­ry pro­duk­ty powsta­ją­ce w tym pro­ce­sie. Dlaczego pisze o dwóch eta­pach? Poniżej wyjaśnienie.

model-driven-architecture-structure

Diagram obra­zu­je produkty/fazy defi­nio­wa­ne jako MDA. Każdy pro­dukt ana­li­zy to okre­ślo­ny zestaw mode­li. Na dia­gra­mie wska­za­no jakich nota­cji uży­wa się w każ­dym z nich (tu bazu­jąc na nota­cjach rodem z OMG). Tu przy­po­mi­nam to co już nie raz pisa­łem: celem jest zro­zu­mie­nie (i two­rze­nia potrzeb­nych w danym przy­pad­ku mode­li) oraz prze­ka­za­ne tej wie­dzy, a nie two­rze­nie jakichś mode­li i doku­men­tów”. Każdy model, jego powsta­nie, ma okre­ślo­ny cel.

Jeszcze sto­sun­ko­wo nie­daw­no w moich pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, wyróż­nia­łem trzy eta­py: ana­li­za orga­ni­za­cji, spe­cy­fi­ka­cja wyma­gań oraz opra­co­wa­nie logi­ki dla dedy­ko­wa­nych kom­po­nen­tów opro­gra­mo­wa­nia. W koń­cu, po kil­ku pro­jek­tach, prze­ko­na­łem się, że ten podział nie dzia­ła”. Dlaczego?

Skoro na eta­pie CIM opra­co­wa­li­śmy mię­dzy inny­mi model logi­ki biz­ne­so­wej dla danej orga­ni­za­cji (w tym regu­ły biz­ne­so­we, słow­nik pojęć) to już ją, te logi­kę, mamy. Okazało się, że ten trze­ci etap” w zasa­dzie jest sztucz­ny, gdyż rze­tel­ne opra­co­wa­nie CIM to tak­że ta” logi­ka. Tu war­to przy­to­czyć diagram:

Swego cza­su pisa­łem tak­że o testo­wa­niu modeli:

W toku dal­szej pra­cy podej­mo­wa­na jest decy­zja o zakre­sie pro­jek­tu. Wskazując to, jakie dzia­ła­nia” ma wspie­rać lub prze­jąć na sie­bie apli­ka­cja (to są wła­śnie przy­pad­ki uży­cia), wska­zu­je­my jaka logi­ka ma być przez tę apli­ka­cję reali­zo­wa­na i kie­dy. Wskazanie zakre­su pro­jek­tu jest więc pierw­szym eta­pem defi­nio­wa­nia logi­ki apli­ka­cji. Jeżeli do tego dodać wie­dzę dzie­dzi­no­wą, np. to któ­re ele­men­ty mogą być współ­dzie­lo­ne a któ­re nie, któ­re powin­ni być cał­ko­wi­cie nie­za­leż­ne itp., powsta­nie tak zwa­ny model dzie­dzi­ny sys­te­mu (logi­ka biz­ne­so­wa i jej struk­tu­ra czy­li archi­tek­tu­ra apli­ka­cji, a kon­kret­nie czę­ści reali­zu­ją­cej logi­kę biznesową).

Na zakończenie

Jak podejść do pla­nów zaku­pu tak­że goto­we­go opro­gra­mo­wa­nia? Czy war­to je pro­jek­to­wać? Oczywiście, że war­to z pro­ste­go powo­du: nie ma zna­cze­nia to, czy przy­szłe opro­gra­mo­wa­nie będzie goto­we czy trze­ba je będzie dopie­ro stwo­rzyć. Ono ma reali­zo­wać taką logi­kę jakiej ocze­ku­je­my. Owszem, jest moż­li­wa decy­zja: sko­ro na ryn­ku nie ma poszu­ki­wa­ne­go pro­duk­tu a stwo­rze­nie dedy­ko­wa­ne­go jest zbyt kosz­tow­ne, to albo rezy­gnu­je­my z zaku­pu albo z okre­ślo­nej logi­ki wewnątrz orga­ni­za­cji. Jednak do pod­ję­cia takiej decy­zji musi­my tę logi­kę znać i mieć udo­ku­men­to­wa­ną (no bo jakoś musi­my ją poka­zać ofe­ren­tom). Ale dostaw­cy opro­gra­mo­wa­nia zawsze ofe­ru­ją ana­li­zę wyma­gań”… To praw­da … A ilu z nich powie, że nie mają Wam nic do zaofe­ro­wa­nia? Ale dedy­ko­wa­ne opro­gra­mo­wa­nie może zapro­jek­to­wać tyl­ko jego wyko­naw­ca”. To dla­cze­go fir­my budow­la­ne nie są dopusz­cza­ne do prac pro­jek­to­wych i architektonicznych?

Dlatego na dia­gra­mie powy­żej, jako moment wybo­ru dostaw­cy opro­gra­mo­wa­nia, wska­za­no ten w któ­rym mamy udo­ku­men­to­wa­ny model logi­ki czy­li PIM. To czy logi­ka taka jest dostęp­na w jakimś pro­duk­cie na ryn­ku czy nie, nie zmie­nia fak­tu, że i tak musi zostać ona opi­sa­na, bez cze­go taki wybór jest nie­moż­li­wy. Czym więc są (czym powin­ny być) wyma­ga­nia na opro­gra­mo­wa­nie? Niestety powin­ny być zwię­złym pro­jek­tem a nie dłu­gą listą cech.

Jeden ana­li­tyk pro­jek­tant mają­cy dobre wspar­cie narzę­dzio­we, jest w sta­nie wyko­nać ana­li­zę i pro­jekt dla dowol­nie dużej fir­my, wystar­czy, że potra­fi two­rzyć abs­trak­cje i zarzą­dzać zło­żo­no­ścią doku­men­ta­cji. Czy kil­ku ana­li­ty­ków zro­bi to nie gorzej i szyb­ciej? Nie znam takie­go przy­pad­ku.… bo im wię­cej osób pro­wa­dzi taką ana­li­zę tym wię­cej pra­cy wyma­ga koor­dy­na­cja i pra­ca nad spój­no­ścią całości.

Na zakoń­cze­nie cytat z pew­nej dyskusji:

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up ?the expe­ri­ment? to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.
2. Our team pro­du­ced more than twi­ce the code of the other teams.
3. Our team achie­ved a 75% reduc­tion in cost.
4. Our team achie­ved a 66% reduc­tion in defect rate.
5. Our team was twi­ce as fast (with half the size).
We have sin­ce got­ten more effi­cient and more advan­ced, so I don?t know what the num­bers are now.
(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).