True Engineering

A few days ago I was talk­ing about the bor­der between require­ments ana­lys­is and engin­eer­ing with Tom Gilb. The con­clu­sion is: that we have to sep­ar­ate the require­ments stage and the engin­eer­ing stage. A huge thank you to Karo­lina Zmitrow­icz for organ­iz­ing this meeting.

True Engin­eer­ing: with Tom Gilb and Jarek Żeliński

UML model and stereotypes as icons

Someone will ask: why all this? The thing is that man­aging present­a­tion graph­ics (mod­el con­sist­ency, tra­cing, etc.) is prac­tic­ally impossible: any change requires inter­fer­ence with block dia­grams and labor­i­ous rein­ser­tion into the ana­lys­is report (I wrote about this in an art­icle about CASE tools). Such graph­ics are not trans­fer­able between tools oth­er than as uned­it­able bit­maps. How­ever, if someone feels that block dia­grams expressed in more «friendly» sym­bols add value to the pro­ject, they can do so. The UML provides for this and many tools allow it (I used Visual-Paradigm).

Source: UML mod­el and ste­reo­types as icons – Jarosław Żeliński IT-Con­sult­ing.

Information architecture, information system vs. information technology in the organisation

There are also simple and obvi­ous conclusions: 

  • there is no point in design­ing an “inform­a­tion sys­tem” without fully under­stand­ing (i.e. also doc­u­ment­ing) the “inform­a­tion system, ”
  • there is no point in pla­cing the ele­ments of the “inform­a­tion sys­tem” on “inform­a­tion sys­tem” mod­els (e.g. There is no point in put­ting the “inform­a­tion sys­tem” ele­ments on “inform­a­tion sys­tem” mod­els (e.g. sym­bols rep­res­ent­ing soft­ware on BPMN models)
  • the rela­tion­ships between the “inform­a­tion sys­tem” ele­ments and the “inform­a­tion sys­tem” ele­ments are described with the help of the trace­ab­il­ity matrix
  • Devel­op­ing the require­ments for the “inform­a­tion sys­tem” is about identi­fy­ing the “busi­ness needs” and devel­op­ing the logic of oper­a­tion and archi­tec­ture of the “inform­a­tion sys­tem” on their basis (MBSE, MDD), and not on col­lect­ing myth­ic­al “user require­ments”, who in fact have no idea about “inform­a­tion sys­tems”, but know very well if and when they need help in the busi­ness pro­cesses being imple­men­ted  this is why meth­ods based on design­ing an “inform­a­tion sys­tem” on the basis of inter­views (work­shops) with future users are doomed to fail­ure from the out­set (because even if some­thing sens­ible is finally cre­ated, it will take a lot of tri­al-and-error work)
  • One thing we have known for years: one of the most dam­aging theses in IT is the one say­ing that a doc­u­ment is a report from a database.

Source: Architek­tura inform­acji, sys­tem inform­acyjny a informatyczny w organ­iz­a­cji – Jarosław Żeliński IT-Consulting

Diagrams in UML notation

UML dia­grams and the way they are used, since the very begin­ning of this nota­tion, have aroused emo­tions and waves of con­flict­ing com­ments. The reas­on for this is the high level of abstrac­tion of the ana­lys­is stage and mod­el­ling as a dis­cip­line, and the fairly wide­spread mis­un­der­stand­ing of the essence of this nota­tion. This is com­poun­ded by the huge dif­fer­ence between what we call ana­lys­is and object-ori­ented design (OOAD) and object-ori­ented pro­gram­ming lan­guages (OOP).UML nota­tion is mis­takenly treated by many people as just anoth­er set of sym­bols for cre­at­ing illus­tra­tions. Most developers I know feel that these dia­grams do noth­ing to help them, and they are gen­er­ally right, because the qual­ity and con­tent of much of the doc­u­ment­a­tion pro­duced with UML, is poor, and such doc­u­ment­a­tion is actu­ally use­less to the soft­ware vendor.

Source: Dia­gramy w not­acji UML – Jarosław Żeliński IT-Consulting

Value-stream mapping i.e. the value stream a company creates when creating its product

The acronym VSM has also star­ted to appear in soft­ware engin­eer­ing for some time now, but it has an old ped­i­gree of more than 30 years. Value-stream Map­ping (VSM), known for 30 years, more recently also as mater­i­al- and inform­a­tion-flow map­ping. It is a meth­od with its ori­gins in Lean Man­age­ment, used to ana­lyse the cur­rent state and design the future state for the series of events that lead a product or ser­vice from order to deliv­ery to the customer.

Source: Value-stream map­ping czyli stru­mień war­tości jaki wyt­war­za firma tworząc swój produkt – Jarosław Żeliński IT-Consulting

What are tests and who tests what

Test­ing is check­ing, and here we have (should have) a clear divi­sion between the check­er and the checked. It is typ­ic­al of the IT mar­ket to tell cus­tom­ers that they have no com­pet­ence in ana­lys­is, test­ing, design, that all this will be done by the soft­ware sup­pli­er. Thus, the fol­low­ing are ordered from the same, single, soft­ware sup­pli­er: busi­ness ana­lys­is, require­ments ana­lys­is, design, imple­ment­a­tion, writ­ing accept­ance tests and test­ing. An entity like the Pur­chaser in essence just watches, and pays as much as the sup­pli­ers want (T&M pro­jects are out of con­trol). In effect, the check­er and checked are the same entity. Does this make sense?

Source: Czym są testy oraz kto i co tes­tuje – Jarosław Żeliński IT-Consulting

SysML – a few words about

In this place, I have been col­lect­ing some speaks about the SysML lan­guage. It is ori­gin from UML (it is a UML pro­file). SysML is the main MBSE meth­od we use for doc­u­ment­ing mechat­ron­ics models. 

Who needs Mod­el Based Sys­tems Engin­eer­ing (MBSE) in 6 minutes
Sys­tems Engin­eer­ing Your MBSE Deploy­ment by Dav­id Long
SysML ?AND? Its Role and Place in Sys­tems Engin­eer­ing with Zane Scott
Intro­duc­tion to Sys­tems Mod­el­ing Lan­guage (SysML)
The Four Pil­lars of SysML 

Ontology-Oriented Data Management and Document Databases

This study presents a meth­od for the stor­age of data organ­ized in digit­al doc­u­ments, which is proven in prac­tice. The dis­cussed meth­od does not bear any dis­ad­vant­ages of the rela­tion­al mod­el used for data organ­iz­a­tion, such as the loss of data con­text and com­plic­a­tions evoked by the lack of data redund­ancy. The meth­od presen­ted here can be used for data organ­iz­a­tion into doc­u­ments (digit­al and paper) as clas­si­fied aggreg­ates and for data clas­si­fic­a­tion. The study also describes a new metamod­el for the data struc­ture which assumes that doc­u­ments, being data struc­tures, form com­pact aggreg­ates, clas­si­fied as objects, or event descrip­tions, thus always assign­ing them a spe­cif­ic and unam­bigu­ous con­text. Fur­ther­more, the study presents a design meth­od for doc­u­ments as con­text aggreg­ates that allows lev­el­ing the dis­ad­vant­ages of the rela­tion­al mod­el and ensures effi­cient inform­a­tion man­age­ment. The work also con­tains prac­tic­al examples of the applic­a­tion of the described method.

Digit­al Doc­u­ments as Data Car­ri­ers and a Meth­od of Data Man­age­ment Guar­an­tee­ing the Unam­bi­gu­ity of the Recor­ded Inform­a­tion: Onto­logy-Ori­ented Data Man­age­ment and Doc­u­ment Databases

Buy and read more…

PIM modelling ‑Reduction of UML notation

The work is an attempt to sys­tem­at­ise the use of key nota­tions in the pro­cess of sys­tem ana­lys­is and design. Under the term. and UML of know­ledge in the field of object-ori­ented ana­lys­is and design and the nota­tion sys­tems used in this area. The author pays spe­cial atten­tion to the dif­fer­ences between data-and respons­ib­il­ity-ori­ented design meth­ods (chapter Ana­lys­is and object-ori­ented design). The fol­low­ing sec­tion describes the con­cep­tu­al basis described in the SBVR, MOF, MDA spe­cific­a­tions and the mod­el­ling meth­od using UML nota­tion. The author argues that onto­logy is not a mod­el of the world, it only describes it.

Read art­icle…

What is Computation Independent Model

1.A Com­pu­ta­tion Inde­pend­ent Mod­el (CIM) is a mod­el defined with­in OMG Mod­el-Driv­en Archi­tec­ture as a primary mod­el. This mod­el reflects sys­tem and soft­ware know­ledge from the busi­ness per­spect­ive. The CIM may con­tain busi­ness know­ledge about sys­tem organ­iz­a­tion, roles, func­tions, pro­cesses and activ­it­ies, doc­u­ment­a­tion, con­straints etc. The CIM must con­tain busi­ness require­ments for the soft­ware system.

(read more)