Archives: Templates

Templates and model types in the QualiWare platform.

Active Directory Sync Setup

The ActiveDirectorySyncSetup template is a system template previously used to synchronize objects between the active directory and QLM. This however is now done in QEF or via the tools menu:

Action

An action can be documented in an UML activity diagram. An action represents a single atomic step within an activity, and is not further decomposed within the activity.

Acknowledge List

The Acknowledge list function enables you to keep track of and document which of your employees have read which relevant documentation.

An acknowledge list is used to select a group of people who must digitally acknowledge that they have read or studied specific sets of documentation. This can for example be a diagram, a document, or a set of regulations. An acknowledge list can be a one to one or a many to many relationships between objects and people. This means that you can have several people, InterestGroups, OrganizationalUnits or several objects listed in the same acknowledge list.

Once a user is assigned to acknowledge an object, the user will get a govenance task, when a new revision of the object is approved. Note as standard the object should be part of the standard “Change Management” governance workflow and the object state, and the Acknowledge is shown when the object is in “Approved” state (read more about the governance workflows here).

An “Acknowledge” action-button is shown in relation to e.g. the Diagram:

The Acknowledge history can be seen on the “Acknowledge History” tab:

 

A user can access their ackowledge task(s) via their “My task” action button in the top right

And from their “To Do list” from the desktop.

Access ArchiMate

Access ArchiMate is one out of three ‘Dependency Relationships’ from the ArchiMate metamodel. IT represents a data dependency and is denoted by a dashed line.

Dependency relationships describe how elements support or are used by other elements. Three types of dependency relationship are distinguished:

  • The servingrelationship represents a control dependency, denoted by a solid line.
  • The accessrelationship represents a data dependency, denoted by a dashed line.
  • The influencerelationship is the weakest type of dependency, used to model how motivation elements are influenced by other elements.

Note that, although the notation of these relationships resembles the notation of the dependency relationship in UML, these relationships have distinct meanings in ArchiMate notation and (usually) point in the opposite direction. One advantage of this is that it yields models with directionality, where most of the arrows that represent such supporting, influencing, serving, or realizing dependencies point ‘upwards’ towards the client/user/business. Another reason for this direction, in particular for the serving relationship, is that it abstracts from the ‘caller’ or ‘initiator’, since a service may be delivered proactively or reactively. The direction of delivery is always the same, but the starting point for the interaction can be on either end. UML’s dependency is often used to denote the latter, showing that the caller depends on some operation that is called. However, for modelling this type of initiative, the ArchiMate language provides the triggering relationship, which can be interpreted as a dynamic (i.e., temporal) dependency. Similarly, the flow relationship is used to model how something (usually information) is transferred from one element to another, which is also a dynamic kind of dependency.

If you want to learn more about the ArchiMate language, you can find the specification here

Accept Event Action

Waits for a specific event (like a signal or message) before proceeding. Useful for event-driven processes.

Abstraction

The Unified Modeling Language (UML) defines an Abstraction as a Relationship that relates two Elements or sets of Elements that represent the same concept at different levels of abstraction or from different viewpoints.

Semantically, an Abstraction is a Dependency that relates two NamedElements or sets of NamedElements that represent the same concept at different levels of abstraction or from different viewpoints. The relationship may be defined as a mapping between the suppliers and the clients. Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. Abstraction has predefined stereotypes (such as Derive, Refine, and Trace) that are defined in UML’s Standard Profile. If an Abstraction has more than one client, the supplier maps into the set of clients as a group. For example, an analysis-level Class might be split into several design-level Classes. The situation is similar if there is more than one supplier.

 

Account

The purpose of the Account template is to enable Financial Risk Management as documented in the Account Context Diagram.

The Account can in its properties be described with:

  • a text description
  • an account number
  • a type (“Profit and loss” or “Balance Account”)
  • link to a responsible Organization Unit
  • description of purpose
  • dates from which the account is valid from and to
  • the currency of the amounts in the account
  • the opening balance of the account
  • the closing balance of the account
  • the amount of the movements on the account
  • a assessment of the account’s significance
  • a rationale behind the account’s significance assessment
  • furthermore, the account can be decomposed into several other accounts

The template can without graphics be linked to other objects under the “Risk – Influences” tab in their properties:

As such, the Account template is linked to objects the same way as the Financial Statement template:

Control Deficiency

The Purpose of the Control Deficiency template is to register a shortcoming of a Control Activity.

The Control Deficiency is used for managing Risk. It can be described with:

  • Date of observation
  • Type of deficiency
    • Design (if the control is not designed properly)
    • Operating (if the control is designed properly, but not performed correctly)
  • Significance (High, medium or low)
  • Observation – description of the deficiency in further detail and/or link to relevant documentation.
  • Link to related process
  • Link to the Control Activity it concerns.
  • Description of any immediate actions taken
  • Link to the person who registered the Control Deficiency
  • Link to other Control Deficiency if it is not the first time it occurs.
  • Description of presumed cause of the deficiency
  • Description of the presumed consequence of the deficiency
  • Recommended actions and their estimated cost and resource requirement

The Recommended action can also be registered in the form of a Corrective Action.

Risk

The Risk template is used for Risk Management purposes and can be linked to all objects in the repository. The Risk template supports the evaluation and continuous handling of the risk.

The Risk can be scored manually on its main tab: “Risk”, where it can also be given a Short Description, Type and Cause:

If you want to score the risk according to more specific categories, you can do so in under the Scoring tab:

You link a risk to the activity it concerns under the “Concerns” tab. Once it has been inserted here, the risk will appear as a “backwards relation” to the Activity. You can also create the risk from the activity and create the backwards relation automatically by using the inherent risk tab on the Activity and click on “Create risk”:

From the Risk-Control tab of Activities, you can also link to the risk. This link indicates that the Activity acts as a mitigating control for the risk. As such, there are two ways a risk can be linked to an activity: either as the activity where the risk is prevalent, or as the control activity that mitigates the likelihood or impact of the risk occurrence:

For more information about how to document Risks in QualiWare: