Validating Software Against HIS Source Code Metrics
The Hersteller Initiative Software (HIS) source code metrics define recommended thresholds for a set of key code quality metrics, to help ensure efficient project and quality management. The HIS Metriken set was originally defined by several large automotive manufacturers (including Audi, BMW Group, DaimlerChrysler, Porsche and Volkswagen), to provide an agreed standard for developing higher quality and more maintainable code for automotive systems.
The HIS metric set is still widely used within the automotive industry today and many of the same metrics are now specifically required by the ISO 26262 automotive functional safety (FuSa) standard (Section 6). However, the guidelines also provide a good general set of code quality and complexity metrics that have found favour in many other areas of embedded and enterprise software development where the need for quality and enforcement of low complexity is of keen interest.
Ensuring Compliance with SciTools Understand
SciTools Understand generates source code architectural and metric data. Through the CodeCheck static analysis functionality, Understand can report instances where the HIS metric boundaries are exceeded.
Automate HIS Compliance
Integrate Understand project analysis into existing build streams. Record per revision quality metrics and, optionally, restrict commits through quality gates.
Configurable
The HIS metrics are often used as part of other coding guidelines, such as KGAS. SciTools Understand allows configuration of the existing metrics, for adjustment of the boundaries, or new metrics to be developed.
HIS Metrics – Metrics with Limits
The HIS Metrics standard defines the following list of metrics with ranges (or limits) of acceptable values.
| Metric | Description | Range |
|---|---|---|
| Comment Density “COMF“ | Relationship of the number of comments (outside of and within functions) to the number of statements | >0,2 |
| Number of paths “PATH“ | Number of non cyclic remark paths (i.e. minimum number of necessary cases of test) | 1 – 80 |
| Number of Goto Statements “GOTO“ | Number of Goto Statements | 0 |
| Cyclomatic Complexity “v(G)“ | In accordance with the Cyclomatic Number (McCabe Cyclomatic Complexity) | 1 – 10 |
| Number of Calling Functions “CALLING“ | By how many subfunctions is this function called | 0 – 5 |
| Number of called functions “CALLS“ | How many different functions does this function call | 0 – 7 |
| Number of Function Parameters “PARAM“ | How complex is the function interface | 0 – 5 |
| Number of Instructions per function “STMT“ | How complex is the function | 1 – 50 |
| Number of call Levels “LEVEL“ | Depth of nesting of a function | 0 – 4 |
| Number of return points “RETURN“ | Number of return points within a function | 0 – 1 |
| The stability index “S“ | The stability index supplies a measure of the number of the changes (changes, deletions, additions) between two versions of a piece of software | 0 – 1 |
| Language scope “VOCF“ | The language scope is an indicator of the cost of maintaining/changing functions | 1 – 4 |
| “NOMV“ | Number of MISRA HIS Subset violations | 0 |
| “NOMVPR“ | Number of MISRA violations per rule | 0 |
| Number of recursions “ap_cg_cycle“ | Call graph recursions | 0 |