4.4. Settings


Figure 4.26 The settings dialog in MQC

4.4.1. Revision granularity

This setting defines the degree of compactions of the revisions for which data exists to better visualize your trend visualizations. The revision granularity can be selected depending on your needs.


Figure 4.27 The default revision granularity is Days, but it might be useful to change it to CalendarWeeks or Months

4.4.2. Calendar week definition

The calendar week definition shows the culture information that was used during the creation of the current project. The culture defines, when the first calendar week of a year actually begin, which is relevant for the calculation of revision names (see Revisions).


Figure 4.28 Select the culture to be used for the calculation of calendar weeks for your project

If an MQC project is shared between areas with different culture information, the calendar week definition, which was initially determined during the creation of the project, is kept. This allows a consistent view on data and quality.

Nevertheless, the initial setting can be adapted with this dialog, if necessary.

4.4.3. Context Categories

Per default the usage of Context Categories is disabled, hence, all data is expected and shown for all artifacts. To apply the context category configuration, enable this setting.

With context categories enabled, for each artifact only expected data is shown in all visualizations (see Figure 4.29). All other data is excluded (white areas of the matrix). By this, you can easily distinguish between not expected data and data that is really missing.


Figure 4.29 Availability Heatmap showing expected data (Context Categories enabled).

Additionally, only expected data is used for calculating quality for an artifact.

4.4.4. Propagation of data

MQC offers the feature to propagate data, that is missing at certain revisions, by using data previously imported instead of importing the data again.

The propagation can be enabled for the whole project, or as propagation between milestones. (see Data Propagation)

4.4.5. Revisions without data

By default MQC hides all empty revisions, for which no data was imported.

This setting allows you to display these configured but empty revisions for all artifacts and measures within this project.

4.4.6. Target values in visualizations (Custom pages)

To make imported Target Values visible in the corresponding visualizations on custom pages (see Custom Pages), enable this setting.

Targets per measure are shown as:

  • separate dashed lines with the same color in trend visualizations

  • horizontal lines in status (bar) visualizations


Figure 4.30 Trend visualization showing a quality property with a corresponding target value


Figure 4.31 Status visualization showing measures with a corresponding target values

4.4.7. Measure values as labels in visualizations (Custom pages)

Value labels can be made visible for status and trend visualizations in custom pages. (see Custom Pages)


Figure 4.32 Trend visualization and Status visualization showing value labels

Enabled value labels are also included in the visualizations of a created report. In a Report value labels provide an alternative to the information that is normally only available via tooltips.

4.4.8. Keep the project up to date

  • by the server-side automation service

    MQC projects with this setting enabled and saved in the server library are updated periodically to fetch the latest data changes.

    Background server-side updates are only executed if new or changed data was detected. This ensures that all relevant projects are always kept up to date.

    See Update Projects on Server for details on how to add a job to the “Automation Services” on the MQC Server to periodically check and update MQC projects.

  • by a client-side automatic data refresh

    MQC projects open in the desktop client and web player use a background monitoring to detect changes in the data of the projects.

    While this setting is disabled, the user is informed of updates by a change in the Data Import State. The user can then update the project by clicking on the “Refresh Data” button provided there.

    While this setting is enabled, any change detected in the data results in a directly executed update of the project in the client, while the user is interrupted in his work and has to wait until the project has been updated.