September, 2020

now browsing by month

 

Business continuity management – how to model it

Busi­ness Con­tinu­ity Man­age­ment (BCM) pro­jects are really dif­fi­cult . The main reas­on is the sys­tem com­plex­ity: many doc­u­ments, many tasks, many pro­cesses, many asso­ci­ations between all of them. Each task con­nec­ted to one or more busi­ness applic­a­tion. Each doc­u­ments stored in dif­fer­ent data­base. The applic­a­tions are integ­rated. Everything works like one chain … but one broken link can crash everything .

How we can man­aging risks? We can cre­ate Busi­ness Archi­tec­ture mod­el and expand this up to Enter­prise Archi­tec­ture, as a mod­el for trace pro­cess, data, IT sys­tem and infrastructure.

(source: https://en.wikipedia.org/wiki/Enterprise_architecture_framework)

How we pre­pare Enter­prise Archi­tec­ture mod­el? Simple ver­sion: pre­pare busi­ness mod­el :

Trans­form this to use case mod­el (applic­a­tion ser­vices) :

Build mat­rix for trace map­ping con­trol :

Trace (map) use case to soft­ware com­pon­ents :

We have com­pleted mod­el, we can do impact ana­lys­is, e.g. what hap­pens and where, when the Ruter go down: 

Some­times we ask: what does the pos­sib­il­ity of car­ry­ing out the Pack­age Goods task depend on?

How can we do this and what tools do we need? Wel­come in my courses, hire me …

References

Kama, N., French, T., & Reyn­olds, M. (2011). Design Pat­terns Con­sid­er­a­tion in Class Inter­ac­tions Pre­dic­tion Devel­op­ment. Inter­na­tion­al Journ­al of Advanced Sci­ence and Tech­no­logy, 28, 21.
Poels, G., Gar­cía, F., Ruiz, F., & Piat­tini, M. (2020). Archi­tect­ing busi­ness pro­cess maps. Com­puter Sci­ence and Inform­a­tion Sys­tems, 17(1), 117–139. https://doi.org/10.2298/CSIS181118018P
Kacem, M. H., Jmaiel, M., Kacem, A. H., & Dri­ra, K. (2006). Trends in Enter­prise Applic­a­tion Archi­tec­ture. Lec­ture Notes in Com­puter Sci­ence, 158–171. https://www.academia.edu/2150818/An_UML-based_approach_for_validation_of_software_architecture_descriptions
McDavid, D. W. (1999). A stand­ard for busi­ness archi­tec­ture descrip­tion. IBM Sys­tems Journ­al, 38(1), 12–31. https://doi.org/10.1147/sj.381.0012
Gomes, S. B., San­toro, F. M., & Mira da Silva, M. (2020). An Onto­logy for BPM in Digit­al Trans­form­a­tion and Innov­a­tion: Inter­na­tion­al Journ­al of Inform­a­tion Sys­tem Mod­el­ing and Design, 11(2), 52–77. https://doi.org/10.4018/IJISMD.2020040103
Shishkov, B. (2020). Design­ing enter­prise inform­a­tion sys­tems mer­ging enter­prise mod­el­ing and soft­ware spe­cific­a­tion.
Hawryszkiewycz, I. T. (2012). Agile Busi­ness Sys­tem Design: Using Inform­a­tion Tech­no­logy to cre­ate busi­ness value (1 edi­tion). Vivid Publishing.

Types instead of inheritance

Many time we can see require­ment writ­ten as a “class dia­gram for pro­ject”. What “class dia­gram” mean? We can use UML class dia­gram for: archi­tec­ture mod­el, notions mod­el, some­times oth­er. Which type of mod­el do you need? Class dia­gram is a tool. When we say mod­el, we have to provided con­text: mod­el of what?

We use inher­it­ance in mod­els of notions (for build­ing tax­onom­ies), nev­er in archi­tec­ture.. In archi­tec­ture mod­els we use types. In 2015 OMG pub­lished UML v.2.5. Inher­it­ance was removed from UML . Why? Wel­come in my courses…

References

OMG.org. (2017, Decem­ber). Uni­fied Mod­el­ing Lan­guage (UML) [OMG.org]. UML. https://www.omg.org/spec/UML/
OMG.org. (2017, Decem­ber 8). Sys­tems Mod­el­ing Lan­guage (SysML). http://www.omgsysml.org/
Weilki­ens, T. (2007). Sys­tems engin­eer­ing with SysML/UML: mod­el­ing, ana­lys­is, design (1. Aufl). Mor­gan Kaufmann OMG Press/Elsevier.
Friedenth­al, S., Moore, A., & Stein­er, R. (2015). A prac­tic­al guide to SysML: the sys­tems mod­el­ing lan­guage (Third edi­tion). Elsevi­er, MK, Mor­gan Kaufmann is an imprint of Elsevi­er. https://www.sciencedirect.com/book/9780128002025/a‑practical-guide-to-sysml

Systems analysis and design

Many time we heard about agile in soft­ware devel­op­ment. Many times authors wrote that agile provide us to fast and cheapest solu­tions. It is true but not all the times. Chaos Report (see Standish Group) show us, that is not true all the times.

Few comments…

Gen­er­ally small pro­jects are not a (big) problem..

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

Water­fall vs. agile: first one meth­od con­sume many more time than second one, but we have no time to «big ana­lys­is». Second one mean «work­ing too fast», and effect is more pro­to­typ­ing mean cost increas­ing… many time mean: can­cel pro­ject before fin­ish caused by budget:

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

A water­fall is not a solu­tion, but agile is not a good rem­edy for it. A com­mon prob­lem in soft­ware design is sys­tem size and complexity:

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

How to improve qual­ity and chance to suc­ceed soft­ware pro­ject? We need really good per­son to busi­ness ana­lys­is role and only one. More than one per­son in a first stage, mean more prob­lem with mer­ging parts to one com­pleted and unam­bigu­ous require­ments doc­u­ment :

(https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf)

Dis­cip­lined agile, what is it? Using mod­els in agile, why and for what? Mod­ern sys­tem ana­lys­is and design is not a water­fall and not a agile style… It is sci­ence meth­od used for soft­ware engin­eer­ing . Dis­cov­er the MDA and pat­terns as a wand for your suc­cess in soft­ware pro­jects. See the sys­tem as a archi­tec­ture .

More about gen­er­al sys­tems and SysML nota­tion com­ing soon …

Try my courses for improve your skills and your team­mates, hire me as a gif­ted per­son in your project.

References

Kurt Bittner. (2011). Use-Case 2.0: Scal­ing up, scal­ing out, scal­ing in for agile pro­jects. https://www.ivarjacobson.com/publications/white-papers/use-case-ebook
Lar­man, C. (2005). Apply­ing UML and pat­terns: an intro­duc­tion to object-ori­ented ana­lys­is and design and iter­at­ive devel­op­ment (3rd ed). Pren­tice Hall PTR, c2005.
Shar­baf, M., Zamani, B., & Sun­yé, G. (2020, Octo­ber). A Form­al­ism for Spe­cify­ing Mod­el Mer­ging Con­flicts. Sys­tem Ana­lys­is and Mod­el­ling (SAM) Con­fer­ence. https://doi.org/10.1145/3419804.3421447
Gra­ics, B., Mol­nár, V., Vörös, A., Majzik, I., & Var­ró, D. (2020). Mixed-semantics com­pos­i­tion of stat­e­charts for the com­pon­ent-based design of react­ive sys­tems. Soft­ware and Sys­tems Mod­el­ing. https://doi.org/10.1007/s10270-020–00806‑5
Gha­ra­jed­aghi, J. (2011). Sys­tems think­ing: man­aging chaos and com­plex­ity: a plat­form for design­ing busi­ness archi­tec­ture (Third Edi­tion). Elsevi­er Inc.
Evans, E. (2014). Domain-driv­en design: tack­ling com­plex­ity in the heart of soft­ware. Addis­on-Wes­ley.
Fowl­er, M. (1997). Ana­lys­is pat­terns: reusable object mod­els. Addis­on Wesley.
Ambler, S. W. (2002). Agile mod­el­ing. John Wiley & Sons.
Gar­cía Díaz, V., Cueva Lov­elle, J. M., Pelayo Gar­cía-Buste­lo, B. C., & San­juán Martínez, O. (Eds.). (2014). Advances and applic­a­tions in mod­el-driv­en engin­eer­ing. Inform­a­tion Sci­ence Reference.
Ambler, S. W. (2004). The object primer. Agile Mod­el-Driv­en Devel­op­ment with UML 2.0 (Third Edi­tion). Cam­bridge Uni­ver­sity Press.