Category Archives: Multi Group Management

KOMEGA REQUIREMENTS: Multi Group Management

Integrating Engineering and the Human Factor (info@uffmm.org) eJournal uffmm.org ISSN 2567-6458, Nov 12 – Dec 13, 2020
Author: Gerd Doeben-Henisch
Email: gerd@doeben-henisch.de

CONTEXT

As described in the uffmm eJournal  the wider context of this software project is a generative theory of cultural anthropology [GCA] which is an extension of the engineering theory called Distributed Actor-Actor Interaction [DAAI]. In  the section Case Studies of the uffmm eJournal there is also a section about Python co-learning – mainly
dealing with python programming – and a section about a web-server with
Dragon. This document is part of the Case Studies section.

CONTENT

Introducing the management of multiple groups working with different projects in parallel.

Update from Dec 10-13, 2020:

During the last sessions with different groups some first procedure shows up like a recipe to prepare the start of a development process using the komega-SW (See the this whole page and some others).

Supported by the complexity planning software — working title ‘komega-SW’ — different groups of experts, which are using one of the possible everyday languages can proceed with the following steps:

  1. They have to decide where — location, city, region, …[SPC] — they want to realize a change process.
  2. Additionally they have to agree about an intended time-frame [TF] within which this change process should happen.
  3. Every intended change process requires at least one vision [V] and some related given realities [R] which will be affected by the change process. There can be many visions in parallel. The visions can also be organized in conceptual hierarchies with most abstract visions on top which then are extended by more concrete visions as far as wanted.
  4. As soon as given realities are associated with a vision these realities can be classified as  problems [P], this means realities which are candidates of an intended change.
  5. The announced visions and the defined problems imply a certain set of actors [A], which will be necessary for the change process.
  6. To start the change process one has finally to define an inital  state, the start state [S_start], which includes the set of realities as a subset, which have  before been declared as problems.
  7. The preceding figure shows the relation between the start situation S_Start as some part of the real everyday world, the kernel state S_Kernel is characterized by those real facts which are are associated with some vision, and then the remaining facts S_Remain which will be enclosed in the start state S_Start beyond the kernel facts.
Update from December 9, 2020:

An Overall Tutorial [DE ] and Example 1 for the German Students in the Modul ‘Kommunalplanung & Gamification. Labor für mehr Bürgerbeteiligung’

tutorial-1-complmngr-v2 (Last change: December 9, 2020)

tutorial-2-complmngr-v1 (Last change: December 9, 2020)

 

Update from December 5, 2020

(This update has been highly influenced by discussions with Philipp Westermeier and Athene Sorokowski from the ZEVEDIINM Team).

The above figure shows a slightly renewed version of the komega SW as a whole. The arguments for this change are discussed elsewhere.

As You can detect by inspection of the new and the old version (figure below) there are three regions in the figure which have been changed: (1) the first module entitled ‘V-R/P-Pref’, (2) the second module entitled ‘Ss’, and (3) the last module entitled ‘EVAL’.

  1. In the original version the concepts ‘Vision’, ‘Problem’ as well as ‘Preferences’ have not been defined very  sharply. This deficiency has been revealed during the first tests. Several discussions have led to the new version now incorporated in the overall concept. According to the mentioned discussion these concepts are now defined as follows: an expert living in some everyday world can use expressions to refer to parts of this reality; these expressions are now called real statements [R]. Such an expert can furthermore use expressions which have no relationship to some known part of the given reality; these expressions are called here vision statements [V] because they are actually non-real. An expert can decide for himself/ herself/ x-self, that such a vision statement in a possible future perhaps can become real. A vision statement would in such a possible future then become turned  into a real statement. An expert having a vision as well as  a real statement can furthermore associate the vision and the real statement in the way of a preference like V > R, saying that he/she/x prefers V before R. After such a decision the reality R as part of the preference V > R is no longer yet a neutral part of reality but appears in the light of the preferred vision V as a problem [P] which can become the object of some change. Whether such a change indeed will happen  depends again from the decision of the expert, to start a change process leading from some initial state S_start to some goal state S_goal. After having defined a vision statement and associated with this vision statement some real statements the expert has to announce all the actors [A] (individual persons, groups, institutions, …) which are involved in the real statement as well in the vision statement.
  2. If the expert decides to start a change process with an initial state S_start then he has to include into this initial state S_start at least all the realities R_i which are occurring in a preference V_i > R_i as  R=∑R_i. Usually the initial state S_start will include other real statements too because the problematic parts of the reality are usually embedded in a richer context with other facts.
  3. If in the described way the expert has explicitly introduced  Visions V and problems P then this allows that the evaluation module EVAL can use these expressions in the following  way: embedded within the simulation process [SIM] the simulator can check after each cycle whether the actual state S contains already vision statements as real statements and that some — or all — of the problem statements have disappeared. According to some predefined threshold θ it is possible then to give a judgment whether the actual state S is already a goal state S_goal or not. A simple formula could be: IF ∑V_i – ∑P_i > θ THEN (S is_goal) is TRUE.
  4. The other change happened in the second evaluation mode:  in this second mode not only the final state of a simulation process will be judged to be a goal state but the whole process will also be weighted! This means that in the vision there can be global visions like being sustainable, but such global  visions can/ must be differentiated with regard to more concrete measures like ‘CO2-free’ or ‘recycling of resources’ something like this. If such visions are defined than the change rules [X] can be enhanced with parameters measuring properties of states and changes with regard to these visions. During evaluation one can then check the final state as described above but one can include also the different parameters measuring important properties of the process. Then perhaps ‘at a first glance’ a state can appear as if it is a goal state, but by including the more fine grained parameters it can turn out, that some of the requirement parameters for the sustainable vision are not satisfied (nice cars bad a worse CO2 balance).
Version before December 5, 2020

PDF DOCUMENT

requirements-Multi-Group-Management12nov2020

PDF DOCUMENT [DE]

A new and enlarged document to serve the needs of some German Audience.

fue-zim-omnikernel