Validierung von Software anhand von HIS-Source Code-Metriken
Die Source Code-Metriken der Hersteller Initiative Software (HIS), definieren empfohlene Schwellenwerte für eine Reihe von wichtigen Code-Qualitätsmetriken. Damit soll ein effizientes Projekt- und Qualitätsmanagement gewährleistet werden. Die Metriken wurden ursprünglich von mehreren großen Automobilherstellern (u. a. Audi, BMW Group, DaimlerChrysler, Porsche und Volkswagen) festgelegt. Ziel war es, einen vereinbarten Standard für die Entwicklung von qualitativ hochwertigerem und besser wartbarem Code für Automobilsysteme zu schaffen.
Die HIS-Metriken werden auch heute noch in der Automobilindustrie verwendet. Viele der gleichen Metriken werden speziell in der ISO-Norm 26262 für funktionale Sicherheit in Kraftfahrzeugen (FuSa) gefordert (Abschnitt 6). Die Richtlinien bieten jedoch auch einen guten allgemeinen Satz von Codequalitäts- und Komplexitätsmetriken. Dadurch haben sie sich in vielen anderen Bereichen der Entwicklung von eingebetteter und unternehmensinterner Software bewährt. Im Mittelpunkt des Interesses stehen dabei die Qualität und die Durchsetzung einer geringen Komplexität.
Gewährleistung der Konformität mit SciTools Understand
SciTools Understand generiert Source Code-Architektur- und Metrikdaten. Durch die statische Analysefunktion CodeCheck kann Understand Fälle melden, in denen die HIS-Metrikgrenzen überschritten werden.
HIS-Konformität automatisieren
Integrieren Sie die Understand-Projektanalyse in bestehende Build-Streams. Aufzeichnung von Qualitätsmetriken pro Revision und optional, Einschränkung von Commits durch Quality Gates.
Konfigurierbar
Die HIS-Metriken werden oft als Teil anderer Codierungsrichtlinien, wie KGAS, verwendet. SciTools Understand ermöglicht die Konfiguration der vorhandenen Metriken, die Anpassung der Grenzen oder die Entwicklung neuer Metriken.
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 |