4.3. Configuration Sources

4.3.1. Project Structure

MQC provides a default project structure if no Project Structure Source has been imported. The default project structure is based on the imported data:

• imported artifacts are shown with their names as read from the data reports, except a proper artifact mapping pattern was added (see Artifact Mapping Patterns)

• a default milestone period is used, which is starting from the date of the first imported data report and which goes until the date of the last imported data report

4.3.1.1. Project Name

MQC allows to define a dedicated project name.

Listing 4.1 Project name definition in YAML

Name: ProjectStructure
Project: SDOACar

In Excel, the project name configuration is done in a separate sheet called ProjectArtifactStructure.

Figure 4.14 Project name definition in Excel

4.3.1.2. Milestones

Milestones in MQC are treated as a time period. A milestone configuration consists of:

• MilestoneName

  The name of the milestone.

• MilestoneStartDate

  The start date of the milestone period. Either, the start date of the project for the first milestone, or one day after the end date of the previous milestone.

• MilestoneDueDate

  The end date of the milestone period respectively the date of the milestone itself.

• MilestoneDuration

  The milestone period duration.

Listing 4.2 Definition of milestones in YAML

Milestones:
- Name: Model Unit Start
  StartDate: 2021-04-27
  DueDate: 2021-06-28
  Duration: 63
- Name: Model Unit Extension
  StartDate: 2021-06-29
  DueDate: 2021-08-16
  Duration: 49
- Name: Model Integration
  StartDate: 2021-08-17
  DueDate: 2021-09-27
  Duration: 42
- Name: Test Improvement
  StartDate: 2021-09-28
  DueDate: 2021-10-18
  Duration: 21

In Excel, the milestone configuration is done in a separate sheet called ProjectMilestoneStructure.

Figure 4.15 Definition of milestones in Excel

It is not necessary to specify each of the parameters MilestoneStartDate, MilestoneDueDate, and MilestoneDuration.

Instead, it is sufficient to specify a project start date as start date of the first milestone phase in combination with a duration for all milestones. It is also possible to define start and end date per milestone without duration.

4.3.1.3. Milestone Structures

Milestones can be defined in sets, which can be organized in a tree structure, so you can easily navigate a lot of milestone sets and quickly enable or disable them. If a project has no need for a milestones structure, you can configure them as explained in Milestones.

Each set of milestones is a consecutive list of dates. Milestones from different sets can overlap or even have the same date.

When using YAML (or JSON) as configuration format:

The milestone structure consists of one or more milestone sets that contain:

• Name

  The name of the milestone set.

• Description

  An optional description of the milestone set.

• Structures

  Multiple milestone sets can be defined in the level below this set.

• Milestones

  Multiple milestones can be defined for this milestone set. The definition is identical to the unstructured Milestones.

There has to at least one Structure and/or Milestone defined in the milestone set.

Listing 4.3 Defining milestone sets and milestones in YAML

MilestoneStructures:
  - Name: 'Process'
    Milestones:
      - Name: Model Unit Start
        StartDate: 2021-04-26
        DueDate: 2021-06-27
      - Name: Model Unit Extension
        DueDate: 2021-08-15
      - Name: Model Integration
        DueDate: 2021-09-26
      - Name: Test Improvement
        DueDate: 2021-10-17
  - Name: 'ECUs'
    Structures:
      - Name: 'EV3C'
        Milestones:
          - Name: Model Implementation
            StartDate: 2021-08-15
            DueDate: 2021-08-25
          - Name: Test Implementation
            DueDate: 2021-09-05
          - Name: Test Refinement
            DueDate: 2021-09-14
          - Name: Test Completion
            DueDate: 2021-10-06
      - Name: 'MVS'
        Milestones:
          - Name: Model Implementation
            StartDate: 2021-07-01
            DueDate: 2021-07-08
          - Name: Test Implementation
            DueDate: 2021-07-15
          - Name: Test Refinement
            DueDate: 2021-08-05
          - Name: Test Completion
            DueDate: 2021-10-06
      - Name: 'OD'
        Milestones:
          - Name: Model Implementation
            StartDate: 2021-04-26
            DueDate: 2021-05-12
          - Name: Test Implementation
            DueDate: 2021-05-21
          - Name: Test Refinement
            DueDate: 2021-05-28
          - Name: Test Completion
            DueDate: 2021-10-06
      - Name: 'GP'
        Milestones:
          - Name: Model Implementation
            StartDate: 2021-06-01
            DueDate: 2021-06-12
          - Name: Test Implementation
            DueDate: 2021-06-20
          - Name: Test Refinement
            DueDate: 2021-06-24
          - Name: Test Completion
            DueDate: 2021-10-06

In Excel a milestone structure can be configured by adding value to the MilestonePath Column in the ProjectMilestoneStructure sheet. The MilestonePath consists of the name-hierarchy of milestone sets concatenated by a dot. (e.g. “ECUs.GP”) When using Excel as the configuration format, you cannot add a description for the milestone sets.

Figure 4.16 Defining milestone paths for milestones in excel

4.3.1.4. Artifacts

With the artifact configuration in the project structure the list of expected project artifacts is defined. A proper artifact configuration consists of:

• ArtifactName

  Mandatory, the name of the artifact.

• ArtifactWeight

  Optional, a weight to define that artifacts may have more or less influence than others. If nothing is set, a weight of 1 is used.

• ContextCategories (optional)

  Context categories (see Context Categories) can be assigned to one or multiple artifacts in the project structure configuration source.

  Listing 4.4 Assign context categories to artifacts in YAML

   Artifacts:
     - Name: EV3Control_main
     - Name: ObstacleDetection
       ContextCategories:
         - MLC_CC
     - Name: GlobalPosition
       ContextCategories:
         - Global_CC
     - Name: ManageVehicleStates
       ContextCategories:
         - MLC_CC
  

  In Excel, the assignment of context categories to artifacts is done within the ArtifactStructure sheet.

  

  Figure 4.17 Assign context categories to artifacts in Excel

  When no context category is assigned, i.e. the field is left empty, all available data is shown for that artifact.

  Details about how to switch on or off categories in MQC can be found in Context Categories.

• ArtifactPath(s)

  Optional, a list of artifact names extracted from data sources to be treated as the same artifact (see Artifacts and Artifact Structure).

  Independent from a specific artifact mapping, MQC allows to define general artifact mapping patterns (see Artifact Mapping Patterns).

• ArtifactStructure

  For details see Artifact Structures.

Listing 4.5 Defining expected artifacts in YAML

Artifacts:
- Name: EV3Control_main
  Weight: 1
  Paths:
  - EV3Control_main
  - EV3Control_demo_ec
  - EV3Control_demo_ec/EV3Control
  Structures:
  - Path: Software.Teams.Components
    Value: SDOAC SW.Team F.Integration
- Name: ObstacleDetection
  Weight: 1
  ContextCategories:
  - MLC_CC
  Paths:
  - ObstacleDetection
  - EV3Control_demo_ec/VehicleManager/ObstacleDetection
  - ObstacleDetection_demo_ec
  - Obstacledetection_demo_ec
  - ObstacleDetection_demo_ec/ObstacleDetection
  Structures:
  - Path: Software.Teams.Components
    Value: SDOAC SW.Team F.Detection

In Excel, the list of expected artifacts is configured within the ArtifactStructure sheet.

Figure 4.18 Defining expected artifacts in Excel using

4.3.1.5. Artifact Structures

Artifact structures can be used in MQC to group artifacts, which can be assigned to a specific path of such a defined structure.

When using YAML (or JSON) as configuration format:

• Multiple hierarchies can defined.

• Each artifact can be assigned to one or multiple hierarchies.

• The hierarchies can have a different amount of levels.

• A description can be added also to structure levels.

Listing 4.6 Defining artifact structures and artifacts with structure assignments in YAML

ArtifactStructures:
- Name: Architecture
  Path: Software.Components
  Values:
    - Name: SDOAC SW
      Description: SDOA Car Software
      Values:
        - Name: Integration
          Description: Integration Model
        - Name: Control
          Description: Control Model
- Name: Responsibility
  Path: Devisions.Teams
Artifacts:
- Name: EV3Control
  Structures:
  - Path: Software.Components
    Value: SDOAC SW.Integration
  - Path: Devisions.Teams
    Value: Development.Team F
- Name: GlobalPosition
  Description: Subsystem for the position of the vehicle
  Structures:
  - Path: Software.Components
    Value: SDOAC SW.Control
  - Path: Devisions.Teams
    Value: Development.Team P

In Excel, the artifact structure configuration is done within the ArtifactStructure sheet (as part of the artifact configuration, see Artifacts).

When using Excel as configuration format:

• Only one hierarchy can be defined.

• Multiple structure levels are allowed.

• Structure levels have to be defined as columns with a column name beginning with “Structure” (e.g. ‘StructureSoftware’ for a structure level called “Software”).

• The order of the levels is defined by the order of the columns in the Excel (e.g. Software > Teams > Components).

Figure 4.19 Defining artifact structures and artifacts with structure assignments in Excel

4.3.2. Quality Model

MQC provides data source specific quality model configurations. These predefined source files can be directly chosen via the “Suggestions” tab within the Add dialog (see Load / Reload).

If no quality model was imported, MQC recognizes the used data sources (either based on the enabled adapters or from the data currently imported) and loads the corresponding quality model suggestions.

These suggestions contain Base Measures, Derived Measures and Quality Properties with a Quality Structure. For Data Details the suggestions also contain Finding Results and Finding Structures for DataSource Adapters that support Data Details.

4.3.2.1. Data

4.3.2.1.1. Base Measures

The base measures configured in the quality model define the set of expected data. When configuring base measures, MQC expects the following information:

• DataSourceName

  The tool/source providing a data report containing data to be imported by MQC. Examples are MXAM and TPT.

• MeasurementName

  A default measurement name, which is used if the measurement can’t be extracted from a report.

  Typically, a measurement means the set of operations done to determine the value for a measure. For example this can be the name of a specific guideline document, which is used for the static analysis of a model, or the kind of test environment like MiL, SiL or PiL.

• BaseMeasureName

  The name for a group of measures, e.g. “FindingCount” for the data source MXAM.

• VariableName

  The name of a specific measure inside a measure group, e.g. “Passed” or “Failed”. Full measure names would then be “FindingCount.Passed” or “FindingCount.Failed”.

• DefaultValue

  The value, which should be set if no value for a specific measure can be extracted from a report, typically 0. (see default-values-configuration)

• Aggregation (optional)

  Combining multiple artifact paths into an artifact can result in more than one data point for the same report at a specific revision and measure. You can specify a aggregation method, sum or avg, to aggregate instead of marking one data point as duplicate and ignoring it.

  Default: None

• Increment (optional)

  Normally, the data imported for a revision contains absolute numbers. If the data of each revision consists only of the changes of the data (increase / decrease) then the Increment can be set to true. Enabling this setting results in a measure value where the imported value is added to the measure value of the previous revision.

  Default: false

Default Values

MQC uses the configured defaults, if the report contains values for at least one other measure belonging to the same base measure group. Otherwise, the whole base measure group is treated as “Missing”.

Listing 4.7 Defining expected base measures with there default values in YAML

BaseMeasures:
- Name: MXAM.GuidelineAnalysis.FindingCount.Aborted
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Canceled
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Failed
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Info
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Passed
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Repaired
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Review
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Unrepaired
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Warning
  DefaultValue: 0
- Name: MXAM.GuidelineAnalysis.FindingCount.Ignored
  DefaultValue: 0

In Excel, the base measure configuration is done in a separate sheet called BaseMeasure.

Figure 4.20 Defining expected base measures with there default values in Excel

4.3.2.1.2. Derived Measures

A fully qualified derived measure consists of:

• DataSourceName

  Optional, typically the name of the data source of the base measures used to calculate the derived measure.

• MeasurementName

  Optional, typically the name of the measurement of the base measures used to calculate the derived measure.

• DerivedMeasureName

  Mandatory, the name for a group of derived measures.

• VariableName

  Mandatory, the name of a specific derived measure inside a derived measure group.

• MeasureFunction

  Mandatory, the expression to calculate a derived measure using base measures and/or other derived measures.

  Base and derived measures must be set in square brackets [ and ]!

If no data source and measurement names are configured (short notation), MQC takes data source and measurement from the base and/or derived measures used to calculate the current derived measure.

This means, if the derived measure configuration is in short notation and the base measures used to calculate the derived measure are provided for multiple measurements (e.g. TestCount.Total for MiL and for SiL), the derived measure will be calculated for all the measurements as well.

To calculate a derived measure for a specific measurement only, fully qualified measure names have to be used inside the measure function.

Listing 4.8 Defining derived measures using a short notation in YAML

DerivedMeasures:
- Name: GuidelinesCalc.Passed
  Expression: '[GuidelineCount.Passed]+log(1+[FindingCount.Passed],2)'
- Name: GuidelinesCalc.Repaired
  Expression: '[GuidelineCount.Repaired]+log(1+[FindingCount.Repaired],2)'
- Name: GuidelinesCalc.Unrepaired
  Expression: '[GuidelineCount.Unrepaired]+log(1+[FindingCount.Unrepaired],2)'
- Name: GuidelinesCalc.Failed
  Expression: '[GuidelineCount.Failed]+log(1+[FindingCount.Failed],2)'
- Name: GuidelinesCalc.Info
  Expression: '[GuidelineCount.Passed with Infos]+log(1+[FindingCount.Info],2)'
- Name: GuidelinesCalc.Review
  Expression: '[GuidelineCount.Review]+log(1+[FindingCount.Review],2)'
- Name: GuidelinesCalc.Warning
  Expression: '[GuidelineCount.Warning]+log(1+[FindingCount.Warning],2)'
- Name: GuidelinesCalc.AbortedCanceled
  Expression: '[GuidelineCount.Aborted]+[GuidelineCount.Canceled]'

In Excel, the derived measure configuration is done in a separate sheet called DerivedMeasure.

Figure 4.21 Defining derived measures using a short notation in Excel

4.3.2.1.3. Context Categories

A context category definition may contain:

• name of the context category

  mandatory, later used to be assigned to artifacts

• expected data

  optional, white list

• excluded data

  optional, black list

Both, expected and excluded data has to be defined using comma-separated lists of data sources, measurements and/or measures. Use either the full name or name patterns (including wildcards).

Listing 4.9 Configuring context categories in YAML

ContextCategories:
- Name: StaticAnalysisOnly
  Expect: MXAM, MXRAY
- Name: TestNoCoverage
  Expect: MXAM, MXRAY, MTest
  Exclude: MTest.*.Model*Coverage

In Excel, the context category configuration is done in a separate sheet called ContextCategory.

Figure 4.22 Configuring context categories in Excel

An empty “Expect” field means, all data is expected for that context category. To state that no data is expected at all, use the key word “none”.

An empty “Exclude” field means, nothing is excluded, but still, the amount of data may be reduced by specifying expected data.

4.3.2.2. Quality

4.3.2.2.1. Quality Properties

When configuring quality properties, MQC expects the following information:

• QualityPropertyName

  Mandatory, the name of the quality property.

• Weight

  Optional, a weight to define that quality properties may have more or less influence than others. If nothing is set, a weight of 1 is used.

• MeasurementFunction

  Mandatory, the expression to calculate a quality property measure value using base measures and/or other derived measures.

  Base and derived measures must be set in square brackets [ and ]!

• Description

  Optional, an explanation of the quality property may be added to document and visualize the background concept.

If the measurement function is defined in short notation and the base and derived measures used to calculate the quality property are provided for multiple measurements (e.g. TestCount.Total for MiL and for SiL), the quality property will be calculated for all the measurements as well.

To calculate a quality property for a specific measurement only, fully qualified measure names have to be used inside the measurement function.

Listing 4.10 Quality property definition in YAML

QualityProperties:
- Name: Testable Requirements with Test Sequences
  Weight: 2
  Expression: [Testable Requirements with Test Sequences.Reached] /
              [Testable Requirements with Test Sequences.Total]
  Description: >
     Show the percentage of the reached testable requirements
     with test Sequences

In Excel, the quality property configuration is done within the QualityModel sheet (together with the quality structure configuration, see Quality Structures).

Figure 4.23 Quality property definition in Excel

4.3.2.2.2. Bin Conditions

When configuring bin conditions, attention must be paid to the following:

• MeasurementFunction

  Instead of a numerical function using base measures and/or derived measures, the term [MQC.Bin] must be used to indicate that the quality property is calculated via a bin condition.

• BinConditions

  For each quality bin a conditional expression must be added. The particular quality bin is assigned, if the expression returns true.

  Bin conditions must be defined in the right order starting with the lowest quality bin up to the highest. This is important for the evaluation of the conditions.

  Please, ensure that all used quality bins are properly defined (see Quality Bins).

Listing 4.11 Using Bin Conditions to define quality properties in YAML

QualityProperties:
- Name: B2B
  Weight: 1
  Expression: '[MQC.Bin]'
  BinConditions:
  - Name: Bad
    Expression: >
      [B2B Statement Coverage.Ratio] is not null and
      [B2B MC/DC Coverage.Ratio] is not null and
      [B2B Test Count.Failed] is not null and
      [B2B Test Count.Error] is not null
  - Name: Acceptable
    Expression: False
  - Name: Good
    Expression: >
      [B2B Statement Coverage.Ratio] = 1 and
      [B2B Test Count.Failed] = 0 and
      [B2B Test Count.Error] = 0

In Excel, the bin condition configuration is split into two parts. The quality property configuration still has to be done within the QualityModel sheet.

Figure 4.24 Quality property definition using bin conditions instead of a measurement function in Excel

Besides, the bin condition configuration is done in a separate sheet called Bin Condition (see Figure 4.24).

4.3.2.2.3. Quality Structures

To group quality properties in order to define different quality aspects, quality structures can be defined.

Quality properties can be assigned to a specific path of such a defined structure.

When using YAML (or JSON) as configuration format:

• Multiple hierarchies can defined.

• Each quality property can be assigned to one or multiple hierarchies.

• The hierarchies can have a different amount of levels.

• A description can be added also to structure levels, not only to quality properties.

Listing 4.12 Definition of a quality model structure and assigning quality properties to this structure in YAML

QualityStructures:
  - Name: Functional Suitability
    Path: Models.Characteristics.Subcharacteristics
    Values:
      - Name: Product Quality Model
        Values:
          - Name: Correctness
            Description: >
               Grouping the quality properties.

               Quality properties in this group evaluate the successful
               operation of the models.
            Values:
              - Name: Model Design
              - Name: Functional Requirements
                Description: >
                   Grouping the quality properties that evaluate the services,
                   the models must offer
              - Name: Test Sequences
              - Name: Assessments
          - Name: Completeness
            Values:
              - Name: Functional Requirements
              - Name: Test Sequences
              - Name: Assessments
              - Name: Model Coverage
              - Name: Code Coverage
  - Name: Quality Assurance Methods
    Path: Quality Assurance.QA Method.QA Work Product
    Values:
      - Name: Product Quality Model
        Values:
          - Name: Static Analysis
            Values:
              - Name: Guidelines Model Design
              - Name: Guidelines Model Architecture
          - Name: Test
            Values:
              - Name: Requirements
              - Name: Test Sequences
              - Name: Assessments
              - Name: Structural Coverage
QualityProperties:
  - Name: Requirements Compliance
    Weight: 3
    Expression: '[Requirements Compliance.Reached] / [Requirements Compliance.Total]'
    Structures:
      - Path: Models.Characteristics.Subcharacteristics
        Value: Product Quality Model.Correctness.Functional Requirements
      - Path: Quality Assurance.QA Method.QA Work Product
        Value: Product Quality Model.Test.Requirements

In Excel, the quality structure configuration is done within the QualityModel sheet.

When using Excel as configuration format:

• Only one hierarchy can be defined.

• Multiple structure levels are allowed.

• Structure levels have to be defined as columns with a column name beginning with “Quality” (e.g. ‘QualityCharacteristics’ for a structure level called “Characteristics”).

• The order of the levels is defined by the order of the columns in the Excel (e.g. Models > Characteristics > Subcharacteristics).

Figure 4.25 Definition of a quality model structure and assigning quality properties to this structure in Excel

4.3.2.3. Data Details

To enable Data Details, expected finding results have to be configured and the data details setting has to be set to All, On Demand or Last Revisions. (see Import data details)

4.3.2.3.1. Finding Results

The finding results are the original results of the findings read by the DataSource Adapters.

This configuration allows to define which of these results are expected, how they should be colored in the visualizations and what the severity for the order of the aggregation should be.

MQC expects the following information for finding results:

• Name

  The name of the result, which is always {DataSource}.{Result}.

• Color

  The color for the visualizations, a 6 digit Hexcode with leading #.

• Severity

  The severity is a number (int) that defines the order of the bins in the aggregation. Only the color of the worst result (= highest severity) is visible in most visualizations.

  In the treemap the size of the elements is based on the number of findings multiplied by the severity.

Listing 4.13 Definition of finding results for datasource MXAM in YAML

FindingResults:
- Name: MXAM.Ignored
  Color: '#F2F2F2'
  Severity: 1
- Name: MXAM.Passed
  Color: '#77AF35'
  Severity: 1
- Name: MXAM.Repaired
  Color: '#A5CF63'
  Severity: 1
- Name: MXAM.Info
  Color: '#67A1DC'
  Severity: 2
- Name: MXAM.Warning
  Color: '#E2DC49'
  Severity: 4
- Name: MXAM.Unrepaired
  Color: '#DFAB3C'
  Severity: 5
- Name: MXAM.Failed
  Color: '#C03F33'
  Severity: 7
- Name: MXAM.Review
  Color: '#864DC2'
  Severity: 8
- Name: MXAM.Aborted
  Color: '#7F7F7F'
  Severity: 9
- Name: MXAM.Canceled
  Color: '#595959'
  Severity: 10

Figure 4.26 Definition of finding results in Excel

4.3.2.3.2. Finding Bin Structures

The purpose for Finding Bin Structures is twofold:

• Unified results between different DataSources

  By grouping similar results of different data sources into a bin the amount of results can be reduced and the results simplyfied.

  Example: “MXAM.Passed”, “TPT.Succeeded”, “TPT.Covered”, “TPT.Linked” and “EmbeddedTester.Justified” could be mapped to a bin named “Passed”.

  The Bin Structure can then be selected in the toolbar, so that the visualizations uses the bins instead of the original finding results.

• Visibility filter to focus on specific result types

  To only show a subset of findings (e.g. Issues), a visibility filter can be configured.

  After a visibility bin is configured, it can be selected in the toolbar to change the visibility of finding results in the KPI, Heatmap and Treemap visualizations. The List is filtered to show only the visible findings.

Definition

MQC expects the following information for finding bin structures:

• Name

  The name of the structure, selectable in the toolbar.

• Bins

  Multiple bins, each consisting of:

  • Name

  The name of the bin, typically a unified result name.

  • Color

  The color for the visualizations, a 6 digit Hexcode with leading #.

  • Severity

  The severity is a number (int) that defines the order of the bins in the aggregation. Only the color of the worst result (= highest severity) is visible in most visualization.

  In the treemap the size of the elements is based on the number of findings multiplied with the severity.

  • Results

  List of Finding Results. (see Finding Results)

  Each Result can only be assigned to one bin of a structure. By using a *, the result assignment can be a wildcard that maches multiple results.

Listing 4.14 Definition of finding bin structures as mapping for selection in YAML

FindingBinStructures:
- Name: Result
  Bins:
  - Name: Passed
    Color: '#77AF35'
    Severity: 1
    Results:
    - '*.Passed'
    - '*.Info'
    - MXAM.Ignored
    - MXAM.Repaired
  - Name: Warning
    Color: '#E2DC49'
    Severity: 4
    Results:
    - '*.Warning'
  - Name: Failed
    Color: '#C03F33'
    Severity: 7
    Results:
    - '*.Failed'
    - MXAM.Unrepaired
  - Name: Review
    Color: '#864DC2'
    Severity: 8
    Results:
    - '*.Review'
  - Name: Error
    Color: '#B40013'
    Severity: 10
    Results:
    - '*.Error'
    - MXAM.Aborted
    - MXAM.Canceled

Listing 4.15 Definition of finding bin structures as visibility in YAML

- Name: State
  Bins:
  - Name: Issues
    Color: '#C03F33'
    Severity: 1
    Results:
    - '*.Warning'
    - '*.Failed'
    - '*.Review'
    - '*.Error'
    - MXAM.Unrepaired
    - MXAM.Aborted
    - MXAM.Canceled
    EnabledForVisibility: true
  Disabled: true

Figure 4.27 Definition of finding bin structures in Excel

If Quality Model Suggestions are used, the Default Data Details Bins are loaded automatically. This configuration can also be manually added as a Quality Model, which is recommended if no custom bins or custom mapping is needed.

4.3.2.3.3. Finding Structures

The Structure of a Finding can be very different from another Finding. Even in the same DataSource the Structure can have a different depth.

To normalize these structures, so that they can be shown in the Heatmap, the Finding Structures can be configured. Unnecessary structure can be removed, additional levels added and names can be freely defined.

MQC expects the following information for finding structures:

• DataSource

  The DataSource of the Findings of this structure.

• Name

  The level name of the structure.

• Index

  The starting index (beginning with 0) in the full structure that is imported by the DataSource Adapter.

  The “Last” keyword is replaced by the last item of the full structure. Simple math expressions are possible.

  If the Index is calculated as less than 0, it is set to 0. If it is calculated greater than the index of the last element it is set to the highest possible index.

• IndexTo (optional)

  Not needed if equal to Index. Multiple parts of the full structure will be combined with a slash (e.g. Chapter 1 / Chapter 2 / Chapter 3).

Example

For the Check “mcheck_misra_slsf_016_a” the following finding structure is read:

Table 4.1 Finding structure for finding of check “mcheck_misra_slsf_016_a”

Index	Element
0	mes_guidelines_embedded_coder_fs
1	Functional Model
2	Simulink
3	Established Design Principles
4	misra_slsf_016_a
5	mcheck_misra_slsf_016_a

Listing 4.16 Version 1: Definition of finding structures in YAML

FindingStructures:
- DataSource: MXAM
  Levels:
  - Name: Documents
    Index: 0
  - Name: Chapters
    Index: 1
    IndexTo: Last-2
  - Name: Guidelines
    Index: Last-1
  - Name: Checks
    Index: Last

Results in:

Table 4.2 Results of Version 1 of check “mcheck_misra_slsf_016_a”

Structure level	Value
Document	mes_guidelines_embedded_coder_fs
Chapter	Functional Model / Simulink / Established Design Principles
Guideline	misra_slsf_016_a
Check	mcheck_misra_slsf_016_a

Listing 4.17 Version 2: Definition of mxam finding structures with subchapters in YAML

FindingStructures:
- DataSource: MXAM
  Levels:
  - Name: Documents
    Index: 0
  - Name: Chapters
    Index: 1
  - Name: Subchapters
    Index: 2
    IndexTo: Last-2
  - Name: Guidelines
    Index: Last-1
  - Name: Checks
    Index: Last

Results in:

Table 4.3 Results of Version 2 of check “mcheck_misra_slsf_016_a”

Structure level	Value
Document	mes_guidelines_embedded_coder_fs
Chapter	Functional Model
Subchapter	Simulink / Established Design Principles
Guideline	misra_slsf_016_a
Check	mcheck_misra_slsf_016_a

The configuration is also possible in Excel, as shown below.

Figure 4.28 Definition of finding structures in Excel

4.3.2.4. Actions

For details about actions, see Actions.

Listing 4.18 Action definition in YAML

QualityProperties:
- Name: Testable Requirements with Test Sequences
  Weight: 2
  Expression: [Testable Requirements with Test Sequences.Reached] /
              [Testable Requirements with Test Sequences.Total]
  Actions:
  - Link test sequences to (covered) requirements
  - Derive further test sequences from uncovered requirements

In Excel, the action configuration is done in a separate sheet called ActionList.

Figure 4.29 Defining recommended actions for improving quality properties in Excel

4.3.3. Target Values

To configure target values in MQC, the following information is necessary:

• ArtifactName

  The name of the artifact a target value shall be applied to.

• MilestoneName

  The name of the milestone a target value shall be reached at.

• MeasureName[.TargetName]

  The name of the measure, data or quality property, a target value shall be applied to, which is optionally followed by a specific target value name:

  • Targets for data measures (fully qualified):

    DataSourceName.MeasurementName.BaseMeasureName.VariableName[.TargetName]

  • Targets for quality properties:

    QualityPropertyName[.TargetName]

• TargetValue

  The value, e.g. a percentage value for quality properties, that is expected to be reached at the date of the configured milestone.

If the configured measure name does not contain a target name at the end, a default target name “Target” is applied by MQC instead.

It is not necessary to define a target for each configured milestone (see Calculation of Target Values per Revision).

Listing 4.19 Defining target values per measure, per artifact and per milestone in YAML

Artifacts:
- Name: ManageVehicleStates
  Milestones:
  - Name: Model Unit Start
    Targets:
    - Name: Guideline Compliance (GuidelineAnalysis)
      Value: 80
    - Name: Requirements Compliance
      Value: 60
  - Name: Model Unit Extension
    Targets:
    - Name: Guideline Compliance (GuidelineAnalysis)
      Value: 80
    - Name: Requirements Compliance
      Value: 80
- Name: EV3Control_main
  Milestones:
  - Name: Model Unit Start
    Targets:
    - Name: Guideline Compliance (GuidelineAnalysis)
      Value: 0
      - Name: Requirements Compliance
        Value: 0
    - Name: Requirements with Reviewed Testability
      Value: 0

In Excel, the target value configuration is done in a sheet called Target Values.

Figure 4.30 Defining target values per measure, per artifact and per milestone in Excel

Details about how to switch on or off targets in MQC can be found in Target values in visualizations (Custom pages).

4.3.4. Annotations

For a proper description of necessary configuration parameters, refer to Annotations.

Mandatory parameters are:

• Title

• Artifact

• Quality Property

Listing 4.20 Defining annotation source in YAML

Authors:
- Model Engineering Solutions GmbH
Annotations:
- Title: 80% because halted for technical reasons
  Author: mqc_admin
  Artifact: EV3Control_main
  QualityProperty: Code Condition Coverage
  ValidFrom: 2021-10-11
  ValidTo: 2021-10-17
  ConditionType: Bin
  ConditionBins:
    - Acceptable
  TargetType: Quality
  TargetValue: 80.00
- Title: Bad because not enough tests
  Author: mqc_admin
  Artifact: GlobalPosition
  QualityProperty: Testable Requirements with Test Sequences
  ValidFrom: 2021-10-11
  ValidTo: 2021-10-17
  ConditionType: Bin
  ConditionBins:
    - Good
  TargetType: Bin
  TargetValue: Bad
- Title: Because Model Coverage - Decision under 80%
  Description: see Data Origins
  Author: mqc_admin
  Artifact: ObstacleDetection
  QualityProperty: Model Decision Coverage
  ValidFrom: 2021-10-11
  ValidTo: 2021-10-17
  ConditionType: Bin
  ConditionBins:
    - Acceptable
  TargetType: Quality
  TargetValue: 75.00

All other configurations are optional and can be added respectively edited later directly in MQC (see Annotations).