Validation des logiciels par rapport aux paramètres du code source HIS
Les métriques de code source Hersteller Initiative Software (HIS) définissent les seuils recommandés pour un ensemble de métriques clés de qualité du code, afin d’assurer une gestion efficace des projets et de la qualité. Le jeu de métriques HIS a été défini à l’origine par plusieurs grands constructeurs automobiles (dont Audi, BMW Group, DaimlerChrysler, Porsche et Volkswagen), afin de fournir une norme agréée pour le développement d’un code de meilleure qualité et plus facile à maintenir pour les systèmes automobiles.
L’ensemble de mesures HIS est encore largement utilisé dans l’industrie automobile aujourd’hui et un grand nombre de ces mesures sont désormais spécifiquement requises par la norme ISO 26262 sur la sécurité fonctionnelle des automobiles (FuSa) (section 6). Toutefois, les lignes directrices fournissent également un bon ensemble général de mesures de la qualité et de la complexité du code qui ont trouvé leur place dans de nombreux autres domaines du développement de logiciels embarqués et d’entreprise où la nécessité de la qualité et de l’application d’une faible complexité est d’un grand intérêt.
Assurer la conformité avec SciTools Understand
SciTools Understand génère des données architecturales et métriques sur le code source. Grâce à la fonctionnalité d’analyse statique CodeCheck, Understand peut signaler les cas où les limites métriques HIS sont dépassées.
Automatiser la conformité au HIS
Intégrer l’analyse des projets d’Understand dans les flux de construction existants. Enregistrer les mesures de qualité par révision et, éventuellement, restreindre les commits grâce à des barrières de qualité.
Configurable
Les métriques HIS sont souvent utilisées dans le cadre d’autres directives de codage, telles que KGAS. SciTools Understand permet de configurer les paramètres existants, d’ajuster les limites ou de développer de nouveaux paramètres.
HIS Metrics – Des métriques avec des limites
La norme HIS Metrics définit la liste suivante de métriques avec des plages (ou limites) de valeurs acceptables.
| 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 |