The Kernel Alphas Diagram ​

OMG Essence standard proposed a method of description/viewpoint for the method of creating and developing systems language of such description and as an example to start the description a set of seven main/kernel (essence, essential, core, in the standard they are called kernel, but the standard itself is called essence) alphas of a software engineering project, and then declared this standard more general, applicable to system engineering as a whole. The standard decomposed these alphas into so-called main/kernel areas of interest, where closely related main alphas were placed. All other alphas were suggested to be considered as sub-alphas of these main ones.

This set of seven main alphas was obtained by an experimental answer to the question: what are the objects of attention of the team present in each development project? More than 250 programming projects were considered, and only those main alphas that literally appeared in each project were included.

For example, not all projects had the system architecture, but in all projects there were requirements---only the requirements made it into the main alphas from all system descriptions, but not the architecture. And the source code was not even considered as part of system descriptions (there was no such alpha), but was almost considered the system itself (it is easy to confuse a working program and its source code!).

The standard had to be adapted in terms of this set of main alphas: it included a language that introduced concepts used to describe the method of creating and developing systems: alphas and sub-alphas, areas of interest, work products, etc., without defining what they are. This was similar to any other software development method description standard (SPEM, ISO 24744), which in their first generation were aimed at methodologists, they also introduced their own language. But OMG Essence was a second-generation standard, it stated that it was oriented towards the developers as its users, and not towards "far from the people" methodologists, therefore, in addition to a language, it proposed a modeling example of the development method---objects of the types proposed in the language, that is, a specific set of main alphas and areas of interest (project opportunity, external project roles, requirements, software system, team, work, way of working), expecting that in each project they would simply attach sub-alphas to them, or even replace this set if it did not fit at all. And it described these alphas, linking them into a system project scheme---this modeling example of the development method with a more or less universal set of main alphas significantly distinguished the second-generation standard from the first-generation standards, which were issued without such an example in the standard text. With the new standard, it was easier to work: it "out of the box" already said something about the development method, which alphas to follow in the project, what states of which alphas to expect.

We have slightly refined^[1] this set of main/kernel alphas and areas of interest, keeping the language of the standard. This is fully provided for in the standard: it says that you can keep the language but replace the main concepts proposed in this language (kernel: a specific set of alphas from several specific areas of interest, to which all other alphas were supposed to be tied as sub-alphas) with other more appropriate ones. This revision turned out to be successful. For example, there are no longer any requirements in life, but they are still in the standard main alphas. So we removed them from the main/kernel set. Instead, we added a system description (assuming that sub-alphas will include the concept of usage, the system concept, "work product," and various other descriptions). You should also refine the main/kernel set of alphas for your project (the material of our course here is only a guide!), but use the language of this standard, that is, types of "alpha," "area of interest," "work product."

These main alphas in the standard were suggested to be connected, this was reflected in the system scheme of the project, and we will present it not for the main alphas from the standard, but for the main set of alphas refined by us:

Here are three areas of interest visible:

• Supra system area of concern (in OMG Essence this roughly corresponds to the customer area of concern). These are states::objects of interest for external project roles::alphas, which give the organization::alphas a commercial opportunity::alpha to carry out the project. The supra system and needs---these are sub-alphas of the opportunity alpha, and also important for the project opportunity are the expected profit from it (the income from the project exceeding the expenses on it). Usage---this is about meeting needs at the moment of use, external project roles pay for satisfaction of needs, for improving the functioning of the supra system from the operation within it of the target system, not just for the operability of the target system at the time of release (testing), they need usage! If the iron works but for some reason does not iron clothes, then there will be no money! If the game software works but the game does not bring pleasure, then there will be no money! If one does not track the alphas of the supra system areas/interests during the entire project, the project results may turn out to be unnecessary---the project opportunity may disappear at any moment during the project, external project roles may stop supporting the project organization materially at any time, "we have the product, but no one is buying it."

• System of interest area of concern (in OMG Essence this is the solution area of concern) relates to the realization, work, and operation/use of the system (on the diagram it is called "operation/service," do not focus on the names!) of the target system. These are the various engineers of the target system who will be dealing with the leading practices of changing the state of the alphas of the interest area of the system of interest during the project---applied engineers who mainly deal with these alphas are engineers of the subject area to which the target system belongs.

• Creator's area of concern relates to the organization carrying out the project (organizational unit performing project: team, a collective from several teams, enterprise, "manufacturing cooperation" of several enterprises, project working group, etc.), work, and organization project description. In the diagram, under the word "project," the alpha "project description" is referred to as the project organization (remember that the word "project" is ambiguous! It can equally mean the work of the organization, the meaning depends on the context). An organization, as a reminder, is a group of people and equipment, where it is clear how the labor and resources management is organized.

Mainly there seem to be three main alphas for each system (two areas of interest of the system of interest and the system of interest creation appear to be almost identically organized):

• System realization, which goes through states of its creation and development (including the created system being used, producing work).
• System description (project/design---all models necessary for creating the system), which gradually appears during the creation and development of the system.
• Works of the ready system during its use, the work method is set by the system description, work plans are calculated on-the-go, or are also set in the description, but the main point is the transition from the time of creation to the time of operation, remembering that the system realization ultimately works, not just is created!

On the other hand, the main alphas in the diagram are not three, but more, as:

• Repetition of the motive from the "three main alphas" in the chain of creation: the project organization::creator (it is separately indicated that this is the creator and highlighted in blue) creates the description of the target system, realizes the system, and often the creator will also be the operator of the created system (there is even a slogan "you built it, you will run it, you will be the operator"). This repetition of the "motive from the three alphas" can be easily continued. For example, it is easy to imagine that if the target system is a machine, then the work of the machine will be creating something in some target system of the client. Only two repetitions of the main alpha set are shown: for the target system (yellow background of the system of interest area of concern) and for the system of interest creation (blue background). By and large, all areas of interest of the systems from the creation chains are the same: system realization and its description (main attention to the time of creation) and work (to avoid forgetting that in the end, what concerns is the moment of use/operation/work/functioning).
• Additionally, all systems have supra systems. The supra system area of interest is attributed to the supra system of the target system and the external project roles in the chain of creating the supra system. The area of interest of the supra systems is highlighted in a green background. In the minimal diagram, only one is shown for the target system (relating to the environment of the target system, for which exist the needs of external project roles, giving a commercial opportunity to the project), hence the singular form---"supra system." There can be multiple different areas of interest for different supra systems for different systems afterward.

These alphas are closely interconnected; not all relationships are shown on the diagram---this is just a reminder that there are many connections, and causes and effects in the project (as in any system) can be significantly spread out in time and space. And there are many more alphas in the project: these are only the highest-level alphas, the main/essence, and they have numerous sub-alphas, which will be explained in more detail later. And this is only two links of the creation chain from a large creation graph that needs to be modeled in the project.

This system project scheme is just a checklist of objects of interest present in the project, that is, a checklist of alphas. Therefore, the graphical representation is not the main thing. The most important thing is to always remember these objects of interest and evaluate changes in the states of these objects of interest: remember the alphas and assess their states. Then choose practices/methods for changing these states of alphas in the desired direction, assigning then the work on these practices to some organizational units. In this way, cohesion is not lost, collective attention of project participants to the alphas is maintained---we check that things are going as expected, what turned out to be unexpected and continue this cycle of "thinking what to do---doing" for a long, long time of creating and developing the system (and, of course, this includes the time of using the system).

If this is just a checklist, then the diagram form is not necessary. Here is an example of a record in the form of a list (the first level is the area of interest, the second level is the alphas):

1. Supra system
   1. Project opportunity
   2. External project roles
2. System of interest
   1. System realization
   2. System work
   3. System description
3. Creator
   1. Project organization
   2. Creation work
   3. Project organization description

This list, when used to monitor the state of the project, has many advantages over the diagram:

• Takes up less space, on a small screen, it is easy to glance through.
• The connections between elements of the list are not displayed. Basically, as noticed in the standard, all alphas in the project are related---not all connections were shown on the diagram, just some, simply to illustrate that these alphas are related in some way. We will assume these relationships, just not write them down.
• This list can be made in any text editor, no need to spend time drawing pictures.
• If desired, the types can be refined, e.g. "supra system::area of interests," "project opportunity::alpha." That’s a quick and clear way, which does not require a graphical editor with special images for language element types, indicating types.
• The main differentiation---it is easy to modify. For example, adding sub-alphas (e.g., adding a client and some oversight to the external project roles, adding the concept of usage and system concept to the system description), a third level will just appear in the list, and, if needed, even a fourth. Easily be sent by email. Easily display revisions. Easily find the desired place in a large list.

The same diagram (graph) can be easily shown, ignoring the displayed relationships between the main alphas, in table format, showing the sub-alpha level as well. In a more general view (as it is quite permissible in the standard language, although in life it is not encountered so often), one sub-alpha can be a sub-alpha of two alphas, but here we simplify—do not plan for such possibilities. We will not show everything in detail, only a few connections, for the convenience of drawing:

Even when combining empty cells in the table, you can simply leave them empty. The use of numbering is not mandatory. If you understand (keep in mind, do not lose sight of) the principles on which this table is based, it will be clear to you and your colleagues. This is just easy modeling with the help of this language/ontology/meta-meta-model as a method of describing what happens in the project of creating and developing a system: