L'approche métrique a été développée à l'origine uniquement à des fins de gestion de projet et pour assurer la conformité des contrats. Une fois les objectifs atteints, ils sont devenus une étude de cas pratique. La performance du projet CCPDS-R n’a jamais été proche de l’optimum ; Au cours du processus d’exécution, un grand nombre d’erreurs ont été constamment commises. Une affirmation similaire est vraie pour le programme de détermination des métriques : parfois il mesurait la mauvaise chose, parfois il mesurait la mauvaise chose. Il n’a pas facilité l’interprétation précoce et a utilisé des méthodes manuelles là où l’automatisation était nécessaire. Cependant, travailler avec des métriques a permis d'améliorer le travail d'équipe, les processus, une meilleure compréhension des risques et, bien sûr, un produit plus efficace. Dans les premiers stades du projet, la direction, les développeurs pratiques et même les observateurs de l'avancement se sont opposés.

contracter. Après la première année, et après plusieurs améliorations en matière d’interprétation, d’automatisation, de présentation et de définition, le soutien a été quasi unanime. Toutes les parties ont utilisé des données objectives du programme de métriques pour éclairer leurs plans, leurs risques, leurs orientations de développement et leurs résultats.

Tous les sous-systèmes de métriques présentés usage général ont été extraits directement des revues mensuelles de gestion de projet. Aucune de ces valeurs n’a été créée après coup. Même si un programme visant à définir des paramètres était une exigence contractuelle, le gouvernement n'a pas précisé quels paramètres devaient être utilisés. Cela a été laissé à la discrétion de l'entrepreneur afin que l'équipe de projet s'approprie le programme de métriques choisi.

TRW a formulé quatre objectifs de programme pour définir des indicateurs :.

Fournir des données pour évaluer les tendances actuelles des performances du projet et déterminer les éléments à prendre en compte lors de la gestion du projet.

Fournir des données pour planifier les étapes suivantes et créer d'autres sous-systèmes.

Fournir des données pour évaluer la difficulté relative de répondre aux exigences de qualité finales.

Fournissez des données pour déterminer quelles améliorations de processus sont nécessaires et justifier leur besoin.

Voici des exemples spécifiques des mesures recommandées au chapitre 13. Plusieurs exemples de mesures permettant de mesurer les progrès sont donnés, ainsi que des mesures de qualité pour les défauts, les retouches et l'achèvement. Décrit les bases requises pour l'automatisation ; ils nécessitent des approches techniques intéressantes qui sont contenues directement dans les produits de conception et de codage.

D.7.1 Progrès du développement.

Mesurer avec précision les progrès du développement avec plusieurs activités simultanées à différentes étapes était un défi pour l'équipe gérant la création du sous-système à usage général. Des efforts considérables ont dû être déployés pour développer une approche cohérente qui fournirait des informations précises sur l'état au niveau du sous-système et l'état de la version. L'objectif était d'obtenir une estimation pondérée qui comprendrait les éléments suivants :

■ Métriques Ada/ADL. Ils ont permis de déterminer assez précisément des indicateurs directs du progrès technique. Ces mesures elles-mêmes reflétaient avec une précision absolue les progrès réalisés dans le développement et la mise en œuvre. Cependant, ils étaient mal adaptés pour décrire les parties achevées du contrat et la situation financière.

■ Indicateurs de valeur ajoutée. Ils ont permis de déterminer avec assez de précision la situation financière et les parties du contrat prêtes à être livrées au client. D’une manière générale, ce sont de mauvais indicateurs du progrès technologique réel.

Comme pour la plupart des autres mesures logicielles, ces deux approches fournissaient initialement des estimations inexactes des progrès absolus. Cependant, ils constituaient d’excellentes estimations des progrès relatifs s’ils étaient suivis régulièrement (mensuellement dans notre cas). À mesure que l’expérience acquise avec ces mesures augmentait, les scores absolus ont été progressivement ajustés pour prédire le succès ou le risque. Les notes globales ont été résumées dans un seul graphique. En figue. D.9 montre les progrès qui en résultent au niveau le plus élevé pour chaque version individuelle et pour le sous-système à usage général dans son ensemble. La longueur de la zone ombrée dans chaque version par rapport à la ligne pointillée (faisant référence au mois en cours) détermine si l'exécution est en avance ou en retard par rapport au calendrier existant. Par exemple, la figure montre l'état après le 17e mois : les tests NT de la version 2 ont un mois de retard, le développement de la version 3 est en avance d'un mois, le développement

Riz. D.9. Progrès général du développement.

Le sous-système à usage général respecte le calendrier prévu, mais les tests HT du sous-système à usage général ont un mois de retard. Les zones ombrées représentent l'évaluation du développeur principal, qui a combiné les indicateurs de progrès mensuels avec les indicateurs mensuels de santé financière pour obtenir un score récapitulatif (et donc quelque peu subjectif).

La collecte mensuelle de valeurs de métriques a fourni à la direction une compréhension détaillée des progrès, de la croissance du code et d'autres métriques obtenues sur chaque version. Des métriques sont collectées pour chaque version et pour CSCI afin d'être considérées sous différents angles. Les responsables* de chaque CSCI ont collecté et évalué leurs mesures avant de les agréger pour l'ensemble du projet. Le processus était objectif, efficace et significatif. Le niveau le plus bas des notes TBD_Statements était, bien sûr, subjectif, mais il a été déterminé par les personnes les plus compétentes : les véritables développeurs. Les partitions ont été stockées au format code source. Cela augmentait la probabilité que ce type de produit de travail contienne les informations les plus récentes. Ce processus a également permis de comparer les progrès réalisés dans différents domaines du projet de manière cohérente et uniforme.

En figue. D.10 fournit des estimations mensuelles des progrès pour le sous-système à usage général et pour chaque version. Le volume de modifications prévu a été basé sur un calcul moyen pondéré approximatif pour chaque version, effectué selon les orientations données dans la section D.5.3 : 30 % du volume créé au moment du PSCP et 70 % du volume par le moment du KSCP. Dans l’ensemble, le sous-système à usage général s’est déroulé presque exactement comme prévu, à une exception près. Les progrès réalisés jusqu'à présent avec le PPOP (bien en avance sur le calendrier) reflètent l'impact positif inattendu des outils de génération de code source. Grâce à son aide, plus de 50 000 SLOC ont été générés pour SAPO.

La conformité de l'œuvre aux plans variait selon la version spécifique. Les progrès réalisés pour le sous-système et pour chaque version ont été évalués mensuellement par la direction interne et le client au moyen d'examens de gestion de projet. Les mesures de progrès ont fourni un mécanisme objectif et un langage convenu pour décrire les modifications apportées aux plans et à l'architecture, les problèmes de conception, les risques de planification et d'autres problèmes liés à la gestion. L'objectivité de cette approche était la composante principale des relations non antagonistes établies entre toutes les parties intéressées.

Tout le monde a compris que même si les valeurs métriques n'étaient pas exactes au début du cycle de vie, elles étaient correctes. Les valeurs absolues étaient rarement importantes. Les tendances relatives étaient plus importantes et, à mesure que le processus progressait, la précision de toutes les mesures augmentait. À l'époque du POP, les valeurs métriques étaient devenues la pierre angulaire de la communication du projet.

Riz. D.10. Progrès réalisés dans le développement du sous-système à usage général D.7.2 Progrès réalisés dans les tests.

L'organisation de test a dû créer des tests d'intégration de versions et des tests de conformité (certains tests NT, FT et OCT). Les tests d'intégration de versions se sont révélés moins efficaces que prévu pour identifier les problèmes. Les tests ITV devaient contenir ensemble complet procédures de test d'intégration - des capacités de base aux conditions limites spéciales. Une grande partie de ce travail, en particulier les fils de discussion principaux, chevauchait le travail d'intégration pour la démonstration. En conséquence, les tests ITV faisaient souvent double emploi avec la préparation des démonstrations, ce qui était moins rentable que si les activités de préparation des démonstrations avaient été combinées avec l'ITV et la responsabilité de celui-ci.

attribué à l’organisation effectuant les tests. Le tableau D.6 présente les résultats de l'ITV de l'étape 2, qui reflètent l'état intégré du produit. Cependant, plus d’efforts que nécessaire ont été consacrés à la planification, à la préparation et à l’exécution de l’ITV. Combiner la préparation des démonstrations avec les activités ITV permettrait à moins de personnel de faire un meilleur travail. Cette approche permettrait une plus grande intégration (dans le cadre du travail de démonstration) avant la revalidation et un backtesting plus efficace après la revalidation pour garantir que tous les problèmes précédents autorisé.

<.>

Tableau D.6.

Caractéristiques SCO pour les tests ITV version 2

Source des problèmes		Modéré (	Gros 0 1 jour)
Interprétation des exigences
Problèmes avec les tests indépendants
Problèmes avec les interfaces
Exécution incorrecte
Extension souhaitable (pas de problème)
Configuration incompatible

Tableau D.7 et Fig. D.11 donne un aperçu des mesures de progrès sous divers angles qui ont été utilisées pour planifier et suivre le programme de tests dans le projet CCPDS-R. La figure montre un graphique des progrès par rapport à ce qui est prévu pour les tests de conformité. Les tests NT, FT et OCT étaient les sources d'options de test utilisées par l'organisation de développement de logiciels. NT relevait de la responsabilité des équipes de développement, mais il devait être réalisé dans un environnement formel de gestion de configuration et sous la supervision (supervision visuelle) du personnel de test. Le FT se composait de groupes de scénarios fonctionnellement interconnectés qui démontraient la conformité aux exigences couvrant plusieurs composants à la fois. Les tests OCT nous ont permis de déterminer des aspects de conformité qui ne pouvaient pas être démontrés auparavant. création complète systèmes. Les exigences quantitatives de performance (QPR) couvraient tous les CSCI.

Les tests HT formels (tests de conformité effectués sous la forme de tests indépendants) se sont avérés plus difficiles que prévu. Cela était principalement dû au fait que les spécifications des exigences et les revues de conception étaient surchargées de détails de développement et de procédures d'approbation.

La mise en œuvre des tests NT formels a été soigneusement contrôlée par le gouvernement et la préparation de l'examen a pris extrêmement longtemps. Le gouvernement a exigé des procédures de tests approfondies pour de nombreux détails de conception individuels qui n'auraient pas dû être considérés comme des exigences. Dans le feu du développement, les procédures HT étaient rarement disponibles 30 à 60 jours avant les nouveaux tests, comme le contrat l'exigeait pour tout type de test de conformité. Le processus formel de test NT était l’une des principales raisons pour lesquelles les réexamens étaient systématiquement terminés plus tard que prévu.

Tableau D.7.

Travaux de tests de conformité utilisant différents types de tests pour différents CSCI

Riz. D.11. Progrès des tests de sous-systèmes à usage général

Type d'essai
Version 0/1 NT
Version 2 NT
Version 3/4/5 NT

D.7.3 Stabilité.

En figue. D.12 indique le niveau général de modification de la configuration de base. Il indique le nombre total de SLOC considérés comme inutilisables (ceux supprimés de la version de base pour amélioration en raison d'un défaut découvert, pour extension ou pour apporter d'autres types de modifications) et le nombre de SLOC restaurés (ceux qui ont été réincorporés dans la version de base. version avec corrections, extensions ou autres modifications). La vitesse à laquelle les défauts ont été découverts, qui différait de la vitesse à laquelle ils ont été corrigés, a entraîné une attention intense de la part de la direction, des changements dans les priorités d'allocation des ressources et des mesures correctives prises pour garantir que l'organisation de test (identifiant les défauts) et l'organisation de développement (effectuer une restauration) sont en équilibre relatif. En général, la situation représentée dans la figure fait référence à un projet extrêmement réussi.

D.7.4 Taux de défauts.

En figue. D.13 Le nombre total de défauts est déterminé par rapport au sous-système logiciel dans son ensemble. Cette mesure estime le total des défauts identifiés lors du développement du sous-système à usage général à environ 25 % du volume de l'ensemble du produit. Le taux de défauts moyen dans l'industrie du logiciel varie de 40 à 60 %. La configuration de base initiale a été établie au moment du POP, au mois 14. Après cela, 1600 y ont été ajoutés modifications individuelles.

Mois d’exécution du contrat Fig. D.13. Taux de défauts dans le sous-système à usage général.

D.7.5 Adaptabilité

Pour le sous-système à usage général dans son ensemble, environ 5 % du travail total a été consacré à la finalisation de la version de base du logiciel. Le coût moyen par changement était d'environ 24 heures par SCO. Ces valeurs permettent d'évaluer la facilité avec laquelle des modifications pourraient être apportées à la version de base du logiciel. Le niveau d'adaptabilité atteint par le projet CCPDS-R était environ quatre fois supérieur à celui des projets conventionnels, dans lesquels les coûts de reprise du cycle de vie dépassent généralement 20 % du niveau de coût total.

En figue. D.14 montre le coût moyen d'un changement dans le processus de création d'un sous-système à usage général. Au moment de l'OCT, 1 600 SCO avaient été traités concernant des modifications de base de configuration, ce qui se traduisait par un coût par modification stable. Le projet CCPDS-R était l’un des rares contre-exemples à l’affirmation suivante : « plus vous avancez dans le cycle de vie, plus vous rencontrez des problèmes coûteux ».

La plupart des premiers SCO (illustrés dans l'encadré intitulé « Modifications du projet » dans la figure D.14) étaient des changements impliquant un grand nombre de personnes et un grand nombre de composants (changements d'interfaces et d'architecture). Les SCO ultérieurs (appelés « Changements dans la mise en œuvre ») se concentraient généralement sur une personne et un composant. La dernière partie de la courbe reflète une augmentation atypique des défauts, résultat d'une vaste proposition technique visant à modifier complètement l'ensemble des messages entrants pour le sous-système à usage général. Ce domaine faisait partie de ces domaines où apporter des changements n’était pas aussi facile que nous l’aurions souhaité. Même si la conception était robuste et adaptable à un grand nombre de scénarios de changement prédéterminés, l’examen de l’ensemble des messages d’entrée n’a jamais été prévu, et la conception n’a pas non plus été conçue pour cela.

Riz. D.14. Adaptabilité Sous-systèmes à usage général.

D.7.6 Complétude.

Le projet CCPDS-R avait des exigences particulières en matière de fiabilité et le logiciel a donc été distribué d'une manière particulière. Une équipe de tests indépendante a créé une suite de tests automatisés. Elle s'est déroulée à des heures impaires et a testé la version de base du logiciel à l'aide de scénarios de messages aléatoires. Cette stratégie a conduit à des tests approfondis dans des conditions réalistes sur une longue période. Sur la base des résultats, il a été possible de déterminer la valeur MTBF du logiciel. Les composants critiques en termes de fiabilité, contraints d'être déplacés dès les premières étapes du plan d'itération, ont été soumis aux tests de fiabilité les plus stricts. Les résultats sont présentés dans la Fig. D.15.

Pour les architectures distribuées modernes, cette méthode de test statistique, d'une part, est nécessaire pour garantir une couverture de test maximale, et d'autre part, elle est utile pour détecter les problèmes associés aux conflits de ressources, aux blocages, à la surcharge de ressources, aux fuites de mémoire et autres. Erreurs d'Heisenberg. L’exécution de scénarios aléatoires et accélérés sur de longues périodes (la nuit ou le week-end) fournit un aperçu précoce de l’intégrité globale des ressources système.

Riz. D.15. Complétude du sous-système à usage général.

D.7.7 Coûts financiers/travaux pour certains types d'activités.

Le tableau D.8 présente la structure globale et détaillée des coûts du sous-système à usage général du projet CCPDS-R. Ces données ont été dérivées du coût final WBS et structurées selon les lignes directrices données dans la section 10.1. Les éléments de niveau inférieur sont décrits dans le Tableau D.9.

■ Les pourcentages indiqués dans le tableau D.8 correspondent à peu près aux pourcentages indiqués dans le chapitre 10. Cependant, certains des éléments de gestion du tableau D.9 ont été répartis sur plusieurs éléments du tableau D.8 pour mettre en évidence les activités au niveau de la gestion du projet. niveau .

■ L'effort global de l'équipe de test s'est avéré relativement faible par rapport aux projets utilisant un processus traditionnel. La raison principale de cet état de fait est que l'équipe d'architecture remettait un système intégré logiciel l'équipe qui a effectué les tests et l'évaluation et qui était principalement responsable des tests du produit intégré.

Tableau D.8.

Dépenses financières au sous-système à usage général basé sur des éléments WBS du plus haut niveau

Élément d'OTP

Tchernikov Alexeï

1. Introduction

Contrairement à la plupart des industries de production matérielle, en matière de projets de développement de logiciels, les approches simples basées sur la multiplication de l'intensité du travail par la productivité moyenne du travail sont inacceptables. Cela est dû tout d'abord au fait que les indicateurs économiques du projet dépendent de manière non linéaire du volume de travail et qu'une erreur importante est autorisée lors du calcul de l'intensité du travail.

Ainsi, pour résoudre ce problème, des méthodes complexes et assez complexes sont utilisées, qui nécessitent une grande responsabilité d'application et un certain temps d'adaptation (ajustement des coefficients).

Des systèmes complets modernes d'évaluation des caractéristiques des projets de développement de logiciels peuvent être utilisés pour résoudre les problèmes suivants :

• évaluation préliminaire, permanente et finale des paramètres économiques du projet : intensité de main d'œuvre, durée, coût ;
  
• évaluation des risques pour le projet : le risque de non-respect des délais et de non-exécution du projet, le risque d'intensité de travail accrue aux étapes de débogage et d'accompagnement du projet, etc.
  
• prendre des décisions de gestion opérationnelle - sur la base du suivi de certaines mesures du projet, il est possible de prévenir rapidement l'apparition de situations indésirables et d'éliminer les conséquences de décisions de conception mal conçues.

1. Introduction
2 métriques
2.1 Métriques orientées dimensionnelles (indicateurs d'estimation de volume)
2.1.1 Évaluation du LOC (lignes de code)
2.1.1.1 Métriques de stylistique et d'intelligibilité des programmes
2.1.2 Total par SLOC
2.2 Mesures de difficulté
2.2.2 Métriques Halstead
2.2.4 Métriques Chapin

2.4 Liste générale des métriques
2.4 Résumé
6 ressources Internet

2. Métriques

Les mesures de complexité du programme sont généralement divisées en trois groupes principaux :

• mesures de la taille du programme ;
  
• mesures de complexité du flux de contrôle du programme ;
  
• mesures de la complexité du flux de données du programme.
  

Les paramètres du premier groupe reposent sur la détermination de caractéristiques quantitatives liées à la taille du programme et sont relativement simples. Les mesures les plus connues de ce groupe incluent le nombre d'instructions de programme, le nombre de lignes de texte source et un ensemble de mesures de Halstead. Les métriques de ce groupe se concentrent sur l'analyse du code source des programmes. Par conséquent, ils peuvent être utilisés pour évaluer la complexité des intermédiaires de développement.

Les métriques du deuxième groupe sont basées sur l'analyse du graphique de contrôle du programme. Un représentant de ce groupe est la métrique McCabe.

Le graphe de contrôle du programme, utilisé par les métriques de ce groupe, peut être construit sur la base d'algorithmes de modules. Par conséquent, les métriques du deuxième groupe peuvent être utilisées pour évaluer la complexité des produits de développement intermédiaires.

Les métriques du troisième groupe sont basées sur l'évaluation de l'utilisation, de la configuration et du placement des données dans le programme. Tout d’abord, cela concerne les variables globales. Ce groupe comprend les métriques Chapin.

2.1 Métriques orientées dimensionnelles (indicateurs d'évaluation du volume)

2.1.1 Évaluation du LOC (lignes de code)

Les métriques orientées dimensions mesurent directement un produit logiciel et son processus de développement. Ces mesures sont basées sur les estimations du LOC.

Ce type de métrique mesure indirectement le produit logiciel et son processus de développement. Au lieu de calculer les scores LOC, il examine la fonctionnalité ou l’utilité du produit plutôt que sa taille.

Le plus répandu dans la pratique de la création logiciel obtenu des métriques orientées dimension. Dans les organisations impliquées dans le développement de produits logiciels, il est d'usage d'enregistrer les indicateurs suivants pour chaque projet :

• coûts totaux de main-d'œuvre (en mois-homme, heures-homme) ;
  
• taille du programme (en milliers de lignes de code source -LOC) ;
  
• Coût de développement;
  
• volume de documentation;
  
• erreurs découvertes au cours d'une année d'exploitation ;
  
• le nombre de personnes travaillant sur le produit ;
  
• période de développement.
  

Sur la base de ces données, des mesures simples sont généralement calculées pour évaluer la productivité du travail (KLOC/mois-homme) et la qualité des produits.

Ces métriques ne sont pas universelles et controversées, en particulier pour un indicateur tel que LOC, qui dépend fortement du langage de programmation utilisé.

Le nombre de lignes de code source (Lines of Code - LOC, Source Lines of Code - SLOC) est le moyen le plus simple et le plus courant d'estimer la quantité de travail sur un projet.

Initialement, cet indicateur est apparu comme un moyen d'évaluer la quantité de travail sur un projet utilisant des langages de programmation avec une structure assez simple : « une ligne de code = une commande de langage ». On sait également depuis longtemps qu'une même fonctionnalité peut être écrite sur un nombre différent de lignes, et si l'on prend le langage haut niveau(C++, Java), il est alors possible d'écrire 5 à 6 lignes de fonctionnalités sur une seule ligne - ce n'est pas un problème. Et ce ne serait pas si mal : moyens modernes les programmes de programmation eux-mêmes génèrent des milliers de lignes de code pour une opération triviale.

Par conséquent, la méthode LOC n’est qu’une méthode d’évaluation (qui doit être prise en compte, mais sur laquelle on ne peut pas s’appuyer dans les évaluations) et n’est en aucun cas obligatoire.

Selon la manière dont un code similaire est pris en compte, il existe deux principaux indicateurs SLOC :

1. le nombre de lignes de code « physiques » - SLOC (les abréviations utilisées sont LOC, SLOC, KLOC, KSLOC, DSLOC) - est défini comme le nombre total de lignes de code source, commentaires et lignes vides compris (lors de la mesure de l'indicateur sur le nombre de lignes vides, une limite est généralement introduite - Lors du calcul, le nombre de lignes vides est pris en compte, qui ne dépasse pas 25 % du nombre total de lignes dans le bloc de code mesuré).
   
2. Le nombre de lignes de code « logiques » – SLOC (les abréviations utilisées sont LSI, DSI, KDSI, où « SI » représente les instructions source) – est défini comme le nombre de commandes et dépend du langage de programmation utilisé. Si le langage ne permet pas de placer plusieurs commandes sur une même ligne, alors le nombre de SLOC « logiques » correspondra au nombre de SLOC « physiques », à l'exception du nombre de lignes vides et de lignes de commentaires. Si un langage de programmation prend en charge le placement de plusieurs commandes sur une seule ligne, une ligne physique doit être comptée comme plusieurs lignes logiques si elle contient plusieurs commandes de langage.
   

Pour la métrique SLOC, il existe un grand nombre de dérivés conçus pour obtenir des indicateurs de projet individuels, les principaux étant :

• nombre de lignes vides ;
  
• nombre de lignes contenant des commentaires ;
  
• pourcentage de commentaires (rapport lignes de code/lignes de commentaire, métrique stylistique dérivée) ;
  
• nombre moyen de lignes pour les fonctions (classes, fichiers) ;
  
• nombre moyen de lignes contenant le code source des fonctions (classes, fichiers) ;
  
• nombre moyen de lignes pour les modules.
  

2.1.1.1 Métriques de stylistique et d'intelligibilité des programmes

Parfois, il est important non seulement de compter le nombre de lignes de commentaires dans le code et de simplement les corréler avec des lignes de code logiques, mais également de connaître la densité des commentaires. Autrement dit, le code a d’abord été bien documenté, puis mal documenté. Ou cette option : l’en-tête d’une fonction ou d’une classe est documenté et commenté, mais pas le code.

Fi = SIGNE (Ncomm. i / Ni – 0,1)

L'essence de la métrique est simple : le code est divisé en n morceaux égaux et Fi est déterminé pour chacun d'eux.

2.1.2 Total par SLOC

Inconvénients potentiels du SLOC visés par les critiques :

• Il est laid et incorrect de réduire l’évaluation du travail d’une personne à quelques paramètres numériques et de juger de sa productivité en fonction de ceux-ci. Le responsable peut affecter les programmeurs les plus talentueux au domaine de travail le plus difficile ; cela signifie que le développement de cette section prendra le plus de temps et générera le plus d'erreurs en raison de la complexité de la tâche. Sans connaître ces difficultés, un autre manager peut décider, sur la base des indicateurs obtenus, que le programmeur a mal fait son travail.
  
• La métrique ne prend pas en compte l'expérience des salariés et leurs autres qualités
  
• Distorsion : Le processus de mesure peut être faussé du fait que les salariés ont connaissance des indicateurs mesurés et cherchent à optimiser ces indicateurs plutôt que leur propre performance. Par exemple, si le nombre de lignes de code source est indicateur important, alors les programmeurs s'efforceront d'écrire autant de lignes que possible et n'utiliseront pas de méthodes de simplification du code qui réduisent le nombre de lignes (voir l'encadré sur l'Inde).
  
• Inexactitude : il n'existe pas de mesures suffisamment significatives et précises. Le nombre de lignes de code est simplement le nombre de lignes ; cet indicateur ne donne pas une idée de la complexité du problème à résoudre. L'analyse des points de fonction a été développée pour meilleure mesure complexité du code et des spécifications, mais il utilise le jugement personnel du mesureur, de sorte que différentes personnes obtiendront des résultats différents.
  

Et la principale chose à retenir : la métrique SLOC ne reflète pas l'intensité de travail nécessaire à la création d'un programme
.

Exemple tiré de la vie : Dans l'une des entreprises, lors de la mise en œuvre, nous avons utilisé cette métrique : nous avons compté les lignes de code. Le chef de l'organisation était en vacances, mais à son retour, il a décidé de profiter de la transparence et de la traçabilité des changements et de voir comment ses managers s'en sortaient avec leurs projets. Et afin de bien comprendre le cours, je suis descendu au niveau le plus bas (c'est-à-dire que je n'ai pas évalué la densité des défauts, le nombre de bugs corrigés) - au niveau des textes sources. J'ai décidé de compter qui a écrit et combien de lignes. Et pour que ce soit vraiment amusant, comparez le nombre de jours de travail par semaine et la quantité de code écrit (la logique est simple : une personne travaillait 40 heures par semaine, ce qui veut dire qu'elle doit écrire beaucoup de choses). Naturellement, il y avait une personne qui n'écrivait qu'une seule ligne par semaine, ne l'écrivait même pas, mais corrigeait seulement celle existante... La colère du manager n'avait pas de limites : il a trouvé un fainéant ! Et ce serait mauvais pour le programmeur si le chef de projet n'expliquait pas que : une erreur a été trouvée dans le programme, un client VIP l'a trouvée, l'erreur affecte l'activité du client et elle doit être corrigée de toute urgence, pour cela ce particulier L'entrepreneur a été sélectionné, qui a déployé le stand, a inondé l'environnement du client, a confirmé l'apparition de l'erreur et a commencé à la rechercher et à l'éliminer. Naturellement, à la fin, il a modifié le morceau de code qui présentait un mauvais état et tout a fonctionné.

D'accord, il est stupide de calculer les coûts de main-d'œuvre à l'aide de cette mesure - une évaluation complète est nécessaire...

2.2 Mesures de difficulté

Outre les indicateurs permettant d'évaluer le volume de travail sur un projet, les indicateurs permettant d'évaluer sa complexité sont très importants pour obtenir des évaluations objectives du projet. En règle générale, ces indicateurs ne peuvent pas être calculés dès les premières étapes des travaux sur un projet, car ils nécessitent au minimum une conception détaillée. Cependant, ces indicateurs sont très importants pour obtenir des estimations prévisionnelles de la durée et du coût du projet, puisqu'ils déterminent directement son intensité de main-d'œuvre.

2.2.1 Métriques orientées objet

DANS conditions modernes La plupart des projets logiciels sont créés sur la base de l'approche OO et il existe donc un nombre important de métriques qui vous permettent d'évaluer la complexité des projets orientés objet.

Métrique	Description
Méthodes pondérées par classe (WMC)	Reflète une mesure relative de la complexité d'une classe basée sur la complexité cyclomatique de chacune de ses méthodes. Une classe avec des méthodes plus complexes et davantage de méthodes est considérée comme plus complexe. Les classes parents ne sont pas prises en compte lors du calcul de la métrique.
Méthodes pondérées par classe (WMC2)	Une mesure de la complexité d'une classe basée sur le fait que la classe a un grand nombre méthodes est plus complexe, et qu’une méthode avec plus de paramètres est également plus complexe. Les classes parents ne sont pas prises en compte lors du calcul de la métrique.
Profondeur de l'arbre d'héritage	La longueur du chemin d'héritage le plus long se terminant dans ce module. Plus l'arbre d'héritage d'un module est profond, plus il peut être difficile de prédire son comportement. Par contre, augmenter la profondeur donne plus grand potentiel réutilisation par ce module du comportement défini pour les classes ancêtres.
Nombre d'enfants	Le nombre de modules qui héritent directement d'un module donné. Des valeurs élevées de cette métrique indiquent une réutilisabilité élevée ; en même temps aussi grande importance peut indiquer une abstraction mal choisie.
Couplage entre objets	Le nombre de modules associés à ce module dans le rôle client ou fournisseur. Un couplage excessif indique une encapsulation modulaire faible et peut empêcher la réutilisation du code.
Réponse pour la classe	Le nombre de méthodes pouvant être appelées par les instances de la classe ; calcule à la fois la somme du nombre de méthodes locales et du nombre de méthodes distantes

2.2.2 Métriques Halstead

La métrique Halsted fait référence à des métriques calculées sur la base de l'analyse du nombre de lignes et des éléments syntaxiques du code source du programme.

La métrique Halstead est basée sur quatre caractéristiques mesurables du programme :

• NUOprtr (Nombre d'opérateurs uniques) - le nombre d'opérateurs de programme uniques, y compris les caractères séparateurs, les noms de procédures et les signes d'opération (dictionnaire des opérateurs) ;
  
• NUOprnd (Nombre d'opérandes uniques) - le nombre d'opérandes uniques du programme (dictionnaire d'opérandes) ;
  
• Noprtr (Nombre d'opérateurs) - le nombre total d'opérateurs dans le programme ;
  
• Noprnd (Nombre d'opérandes) - le nombre total d'opérandes dans le programme.
  

Sur la base de ces caractéristiques, des scores sont calculés :

• Dictionnaire des programmes
  (Vocabulaire du programme Halstead, HPVoc) : HPVoc = NUOprtr + NUOprnd ;
  
• Durée du programme
  (Durée du programme Halstead, HPLen) : HPLen = Noprtr + Noprnd ;
  
• Portée du programme
  (Volume du programme Halstead, HPVol) : HPVol = HPLen log2 HPVoc ;
  
• Complexité du programme
  (Difficulté Halstead, HDiff) : HDiff = (NUOprtr/2) × (NOprnd / NUOprnd) ;
  
• Sur la base de l'indicateur HDiff, il est proposé d'évaluer les efforts de développement du programmeur à l'aide de l'indicateur HEff (Halstead Effort) : HEff = HDiff × HPVol.
  

2.2.3 Métriques de complexité cyclomatique de McCabe

L'indicateur de complexité cyclomatique est l'un des indicateurs les plus courants pour évaluer la complexité des projets logiciels. Cet indicateur a été développé par le scientifique McCabe en 1976, appartient au groupe d'indicateurs permettant d'évaluer la complexité du flux de contrôle d'un programme et est calculé sur la base du graphique logique de contrôle du programme (graphique de flux de contrôle). Ce graphe est construit sous la forme d'un graphe orienté, dans lequel les opérateurs ou expressions de calcul sont représentés sous forme de nœuds, et le transfert de contrôle entre nœuds est représenté sous forme d'arcs.

L'indicateur de complexité cyclomatique permet non seulement d'évaluer l'intensité de travail de la mise en œuvre des éléments individuels d'un projet logiciel et d'ajuster les indicateurs globaux pour estimer la durée et le coût du projet, mais également d'évaluer les risques associés et de prendre les décisions de gestion nécessaires.

Une formule simplifiée pour calculer la complexité cyclomatique est la suivante :

C = e – n + 2,

Où e – nombre de côtes , et n - nombre de nœuds
sur le graphique logique de contrôle.

Généralement, les opérateurs logiques ne sont pas pris en compte lors du calcul de la complexité cyclomatique.

Dans le processus de calcul automatisé de l'indicateur de complexité cyclomatique, en règle générale, une approche simplifiée est utilisée, selon laquelle le graphique n'est pas construit et l'indicateur est calculé sur la base du comptage du nombre d'opérateurs logiques de contrôle (si, commutateur, etc.) et le nombre possible de chemins d'exécution des programmes.

Le nombre cyclomatique de McCabe indique le nombre de passes nécessaires pour couvrir tous les circuits d'un graphe étroitement connecté, ou le nombre d'exécutions de tests d'un programme requis pour des tests exhaustifs « chaque branche fonctionne ».

L'indicateur de complexité cyclomatique peut être calculé pour un module, une méthode et d'autres unités structurelles du programme.

Il existe un nombre important de modifications de l'indicateur de complexité cyclomatique.

• Complexité cyclomatique « modifiée » – ne considère pas chaque branche d’un opérateur à choix multiples (switch), mais l’opérateur dans son ensemble comme un tout unique.
  
• Complexité cyclomatique « stricte » – inclut les opérateurs logiques.
  
• Calcul « simplifié » de la complexité cyclomatique - implique un calcul non pas sur la base d'un graphique, mais sur la base du comptage des opérateurs de contrôle.
  

2.2.4 Métriques Chapin

Il en existe plusieurs modifications. Considérons une version plus simple et du point de vue de l'utilisation pratique, assez efficace de cette métrique.

L'essence de la méthode est d'évaluer la force informationnelle d'un seul module logiciel en analysant la nature de l'utilisation des variables de la liste d'entrées-sorties.

L'ensemble des variables qui composent la liste d'E/S est divisé en quatre groupes fonctionnels.

Q = a1P + a2M + a3C + a4T, où a1, a2, a3, a4 sont des coefficients de pondération.

Q = P + 2M + 3C + 0,5T.

2.3 Évaluation préliminaire basée sur des méthodes statistiques en fonction des étapes de développement du programme

Lors de l'utilisation d'outils intégrés d'entreprises développant solutions standards(cette catégorie comprend ce qu'on appelle les « inhausers » - les entreprises engagées dans le service de l'activité principale), il devient possible de faire des prévisions sur la complexité des programmes sur la base des statistiques collectées. La méthode statistique est bien adaptée pour résoudre de tels tâches typiques et ne convient pratiquement pas à la prévision de projets uniques. Dans le cas de projets uniques, d'autres approches sont utilisées, dont la discussion dépasse le cadre de ce document.

Les tâches typiques vont d'une corne d'abondance de services commerciaux aux départements de développement, de sorte qu'une évaluation préliminaire de la complexité pourrait grandement simplifier les tâches de planification et de gestion, d'autant plus qu'il existe une base de données accumulée pour les projets dans laquelle sont stockés non seulement les résultats finaux, mais également tous les premiers et les intermédiaires.

Soulignons les étapes typiques du développement d'un programme :

• élaboration des spécifications des exigences du programme ;
  
• définition de l'architecture ;
  
• développement de la structure modulaire du programme, développement des interfaces entre modules. Développement d'algorithmes;
  
• développement et tests de code.
  

Essayons maintenant d'examiner un certain nombre de mesures qui sont souvent utilisées pour l'évaluation préliminaire au cours des deux premières étapes.

2.3.1 Évaluation préliminaire de la complexité du programme au stade de l'élaboration des spécifications des exigences du programme

Pour évaluer les résultats de cette étape, la métrique du nombre prédit d'opérateurs Nprog du programme peut être utilisée :

Nprogn =NF*Nunité

Où : NF – nombre de fonctions ou d'exigences dans la spécification des exigences pour le programme en cours d'élaboration ;
Ned – valeur unique du nombre d'opérateurs (nombre moyen d'opérateurs par utilisateur) fonction moyenne ou exigence). La valeur de Ned est statistique.

2.3.2 Évaluation préliminaire de la complexité au stade de la définition de l'architecture

Si = NI / (NF * NIed * Ksl)

Où:
NI – le nombre total de variables transmises via les interfaces entre les composants du programme (également statistique) ;
NIed – une valeur unique du nombre de variables transférées sur les interfaces entre les composants (le nombre moyen de variables transférées sur les interfaces pour une fonction ou une exigence moyenne) ;
Ksl est le coefficient de complexité du programme en cours de développement, prend en compte l'augmentation de la complexité unitaire du programme (complexité pour une fonction ou exigence de la spécification des exigences du programme) pour les programmes volumineux et complexes par rapport au logiciel moyen.

2.4 Liste générale des métriques

Le tableau 1 contient une brève description des mesures qui ne sont pas incluses dans la description détaillée ci-dessus, mais ces mesures sont néanmoins nécessaires et importantes, elles sont simplement statistiquement beaucoup moins courantes.

Notez également que le but de cet article est de montrer le principe, et non de décrire toutes les métriques possibles dans de nombreuses combinaisons.

Dans cet article, je souhaite examiner certaines des mesures d’assurance qualité les plus importantes à mon avis. Il s'agira de tels indicateurs, coefficients et indicateurs qui vous permettront de dresser un portrait global de ce qui se passe sur le projet en termes de qualité et de déterminer les étapes pour l'améliorer. Les mesures couvriront 5 domaines différents : les exigences, la qualité des logiciels, l'efficacité de l'équipe de test, la qualité du travail d'assurance qualité et les commentaires. Il est important de mesurer et de suivre les indicateurs simultanément dans différentes sections du processus de développement logiciel afin de détecter les problèmes courants et fondamentaux et d'être en mesure de configurer et d'optimiser l'ensemble du processus.

Groupe 1 - Exigences pour le logiciel en cours de développement

Ce groupe de mesures nous permettra d'évaluer dans quelle mesure nous avons élaboré les exigences (user story) du logiciel, d'identifier les vulnérabilités et les fonctionnalités logicielles les plus complexes et potentiellement problématiques, et de comprendre où un contrôle spécial est requis :

1. Exigences de couverture des tests

En d’autres termes, il s’agit du nombre de tests par exigence.

Objectif métrique : identifier les faiblesses dans la couverture des tests et mettre en évidence les risques.

• Bien entendu, cette métrique ne fonctionnera que si les exigences sont bien décomposées et plus ou moins équivalentes. Bien sûr, cela n'est pas toujours possible, mais si vous pouvez rendre les exigences suffisamment atomiques, alors cette métrique montrera l'écart de la couverture de chaque exigence par rapport au niveau moyen. Plus la valeur diffère de 1, moins/plus de tests sont écrits pour une exigence que d'habitude.
• La chose la plus importante à laquelle il faut prêter attention sont les exigences pour lesquelles le coefficient sera égal ou proche de 0. Pour celles-ci, il faut penser à ajouter des tests.
• Si les exigences ne sont pas atomiques, cette métrique garantira uniquement qu'il y a au moins 1 test pour chaque exigence. Pour cela, le coefficient doit toujours être supérieur à 0.

2. Degré d’interdépendance des exigences

La métrique est calculée comme le nombre moyen de connexions de chaque exigence avec d’autres exigences.

Objectif métrique : fournir une base pour évaluer le calendrier des tests et prendre en compte les risques possibles. Connaissant le degré d'influence mutuelle des exigences les unes sur les autres, vous pouvez, par exemple, prévoir du temps et des cas supplémentaires pour des tests de bout en bout, travailler sur des contrôles de régression, envisager l'intégration, etc.

• La valeur de cette métrique sera comprise entre 0 et 1. 1 signifie que chaque exigence est liée à chacune et 0 signifie qu'il n'y a aucune relation.
• Il est difficile d'introduire des restrictions sur les valeurs de ce coefficient, cela dépend beaucoup des spécificités de la fonctionnalité, de l'architecture et des technologies. Cependant, d'après ma propre expérience, je peux dire que c'est bien lorsque le degré de connectivité ne dépasse pas 0,2-0,3. Dans le cas contraire, une modification dans le cadre d'une des exigences entraînera une chaîne de changements, et donc erreurs possibles, dans une partie importante du produit.

3. Facteur de stabilité des exigences

Objectif métrique : montre combien d'exigences déjà implémentées doivent être refaites d'une version à l'autre lors du développement de nouvelles fonctionnalités.

• Bien entendu, il n'existe pas de fonctionnalités complètement isolées, mais le nombre de nouvelles exigences doit prévaloir sur celles qui changent, et le coefficient doit être de préférence inférieur à 0,5. Dans ce cas, nous introduisons 2 fois plus de nouvelles fonctionnalités que nous ne retravaillons celles existantes.
• Si le coefficient est supérieur à 0,5, surtout s'il est supérieur à 1, cela signifie très probablement que nous avons déjà fait quelque chose qui s'est avéré inutile. L'équipe ne se concentre pas sur la création de nouvelles valeurs commerciales, mais sur la refonte des fonctionnalités précédemment publiées.
• La métrique donne également une idée de la facilité avec laquelle les fonctionnalités du système peuvent être mises à l’échelle et de nouvelles fonctionnalités ajoutées.

Groupe 2 - Qualité du produit en cours de développement

Comme son nom l'indique, ce groupe de métriques démontre la qualité du logiciel, ainsi que la qualité du développement lui-même.

1. Densité des défauts

Le pourcentage de défauts par module individuel lors d'une itération ou d'une version est calculé.

Objectif métrique : mettez en évidence quelle partie du logiciel est la plus problématique. Ces informations aideront à évaluer et à planifier le travail avec ce module, ainsi qu'à analyser les risques.

• Causes grande quantité les défauts d'un module spécifique (coefficient supérieur à 0,3) peuvent être différents : exigences de faible qualité, qualifications des développeurs, complexité technique, etc. Dans tous les cas, cette métrique attirera immédiatement notre attention sur la zone problématique.

2. Coefficient de régression

Objectif métrique : montrer où vont les efforts de l’équipe : sommes-nous davantage impliqués dans la création et le débogage de nouvelles fonctionnalités ou sommes-nous obligés de mettre à jour les parties existantes du logiciel la plupart du temps ?

• Plus le coefficient est proche de 0, moins d'erreurs ont été introduites dans la fonctionnalité existante lors de la mise en œuvre de nouvelles exigences. Si la valeur est supérieure à 0,5, nous passons alors plus de la moitié du temps à restaurer les fonctions logicielles qui fonctionnaient auparavant.

3. Taux de défauts réouverts

Objectif métrique :évaluer la qualité du développement et de la correction des défauts, ainsi que la complexité du produit ou du module individuel

• Cette métrique peut être calculée pour l’ensemble du logiciel, un module individuel ou une fonctionnalité. Plus la valeur résultante est proche de 0, moins les anciennes erreurs se répètent au cours du développement.
• Si le coefficient s'avère supérieur à 0,2-0,3, cela peut indiquer soit la complexité technique du module et ses exigences hautement associées, soit une architecture maladroite, soit que le correctif précédent a été mal conçu.

4. Coût moyen de réparation d'un défaut

Le rapport entre le montant des coûts engagés par l'équipe lorsqu'elle travaille avec tous les défauts (par exemple, dans le cadre d'une version) par rapport au nombre total de défauts.

Objectif métrique : montrent combien il nous coûte cher de détecter et de corriger chaque défaut. Cela permettra de calculer les bénéfices de la réduction du nombre d'erreurs commises et d'évaluer la faisabilité des techniques appropriées.

• Bien sûr, il n'y a pas de valeurs correctes ici, tout sera déterminé par les spécificités d'une situation particulière

5. Nombre de défauts dans le code d'un développeur spécifique

Objectif métrique : mettre en évidence d'éventuelles difficultés au sein de l'équipe de développement, quels spécialistes manquent d'expérience, de connaissances ou de temps et ont besoin d'aide.

• Si, par exemple, 50 % de tous les défauts sont imputables à 1 développeur et qu'il y en a 5 dans l'équipe, alors il y a clairement un problème. Cela ne veut pas dire que ce programmateur ne fonctionne pas bien, mais cela signale qu'il est impératif de comprendre les raisons de cette situation.
• La métrique, entre autres choses, peut être un indicateur d’un module/fonctionnel/système particulièrement difficile à développer et à prendre en charge.

Groupe 3 – Capacité et efficacité de l’équipe d’assurance qualité

L’objectif principal de ce groupe de métriques est d’exprimer en chiffres ce dont l’équipe de test est capable. Ces indicateurs peuvent être calculés et comparés régulièrement, les tendances peuvent être analysées et on peut observer comment le travail de l’équipe est affecté par certains changements.

1. Vélocité de l'équipe d'assurance qualité

Il est calculé comme le rapport des story points (ou exigences, ou user stories) implémentés sur plusieurs, par exemple 4 à 5 itérations (Sprint) par rapport au nombre d'itérations sélectionnées.

Objectif métrique : exprimer numériquement les capacités et la rapidité du travail de l'équipe pour une planification plus approfondie de l'étendue des travaux et une analyse des tendances de développement

• La métrique vous permet de surveiller la vitesse du travail d'assurance qualité et d'observer quels processus internes ou influences externes sur l'équipe peuvent affecter cette vitesse.

2. Durée de vie moyenne des défauts

Durée totale pendant laquelle les défauts détectés dans une itération ou une version étaient ouverts à la somme des défauts.

Objectif métrique : montrez combien de temps il faut en moyenne pour travailler avec un défaut : l'enregistrer, le corriger et le reproduire. Cet indicateur vous permettra d'estimer le temps nécessaire aux tests et de mettre en évidence les domaines du logiciel avec lesquels surviennent les plus grandes difficultés.

• En règle générale, la durée de vie d'un défaut correspond à la durée totale depuis sa création (statut Créé) jusqu'à sa fermeture (Fermé), moins tous les reports et mises en attente possibles. N'importe quel outil de suivi de bogues vous permet de calculer et de télécharger cette information pour un sprint ou une version individuelle.
• De plus, la durée de vie moyenne d'un défaut peut être calculée pour différents modules et fonctions logicielles, ou, plus intéressant encore, séparément pour chacun des testeurs et développeurs de l'équipe. Cela vous donne la possibilité d'identifier des modules particulièrement complexes ou un maillon faible dans l'équipe logicielle.

Groupe 4 - Qualité du travail de l'équipe de tests

Le but de cet ensemble de mesures est d'évaluer dans quelle mesure les testeurs accomplissent leurs tâches et de déterminer le niveau de compétences et de maturité de l'équipe d'assurance qualité. Disposant d'un tel ensemble d'indicateurs, vous pouvez comparer l'équipe avec elle-même à différents moments ou avec d'autres groupes de test externes.

1. Efficacité des tests et des cas de tests

Objectif métrique : montrent combien d'erreurs en moyenne nos cas peuvent détecter. Cette métrique reflète la qualité de la conception du test et permet de surveiller la tendance de son évolution.

• Il est préférable de calculer cette métrique pour tous les ensembles de tests : pour des groupes distincts de tests fonctionnels, un ensemble de régression, des tests de fumée, etc.
• Cet indicateur de « létalité » des tests permet de suivre l'efficacité de chacun des kits, son évolution dans le temps et de les compléter par des tests « frais ».

2. Taux d'erreurs manquées par production

Nombre d'erreurs découvertes après la sortie \ nombre total d'erreurs dans le logiciel découvertes lors des tests et après la sortie

Objectif métrique : démontrer la qualité des tests et l'efficacité de la détection des erreurs - quelle proportion de défauts a été filtrée et quelle proportion a été mise en production.

• Le pourcentage acceptable d’erreurs manquées lors de la production dépendra bien entendu de nombreux facteurs. Cependant, si le coefficient est >0,1, c'est mauvais. Cela signifie qu'un défaut sur dix n'a pas été détecté lors des tests et a entraîné des problèmes dans le logiciel déjà distribué aux utilisateurs.

3. Temps de travail réel de l'équipe QA

Le rapport entre le temps consacré par l'équipe directement aux activités d'assurance qualité et le nombre total d'heures.

Objectif métrique : premièrement, pour augmenter la précision de la planification, et deuxièmement, pour surveiller et gérer les performances d'une équipe particulière.

• Les activités cibles comprennent l'analyse, la conception, les évaluations, les tests, les réunions de travail et bien plus encore. Les effets secondaires possibles sont des temps d'arrêt dus à des bloqueurs, des problèmes de communication, l'indisponibilité des ressources, etc.
• Naturellement, ce coefficient ne sera jamais égal à 1. La pratique montre que pour des équipes efficaces, il peut être de 0,5 à 0,6.

4. Précision de l'estimation du temps par domaine\types\types de travail

Objectif métrique : permet l’utilisation d’un facteur de correction pour les évaluations ultérieures.

• Le degré de précision de l'évaluation peut être déterminé pour l'ensemble de l'équipe ou pour des testeurs individuels, pour l'ensemble du système ou pour des modules logiciels individuels.

5. Part des défauts non confirmés (rejetés)

Objectif métrique : montrer combien de défauts ont été créés « sans rien faire ».

• Si le pourcentage de défauts rejetés dépasse 20 %, l'équipe peut alors connaître une désynchronisation dans la compréhension de ce qui est un défaut et de ce qui ne l'est pas.

Groupe 5 - Commentaires et satisfaction des utilisateurs

Et enfin, un groupe de métriques montrant comment le produit a été accepté les utilisateurs finauxà quel point cela a répondu à leurs attentes. Mais les commentaires sur les logiciels ne sont pas les seuls à être importants : une autre tâche importante de ce groupe de métriques est de montrer si les utilisateurs sont satisfaits du processus d'interaction avec l'équipe informatique en général et avec l'assurance qualité en particulier.

1. Satisfaction des utilisateurs à l'égard des services informatiques

Enquête régulière sur la satisfaction des utilisateurs vis-à-vis des services informatiques avec scoring.

Objectif métrique : montrer si les utilisateurs font confiance à l'équipe informatique, s'ils comprennent comment et pourquoi son travail est organisé et dans quelle mesure ce travail répond aux attentes.

• La métrique peut servir d'indicateur qu'il est nécessaire de se concentrer sur l'optimisation du processus ou de le rendre plus clair et plus transparent pour les utilisateurs.
• L'indicateur de satisfaction peut être calculé à partir des résultats d'une enquête suite à la diffusion. Nous collectons toutes les notes et calculons la note moyenne. Ce score peut ensuite être recalculé une fois que des modifications ont été apportées au processus.

2. Satisfaction des utilisateurs avec le produit

Enquête régulière auprès des utilisateurs sur leur satisfaction à l'égard du produit.

Objectif métrique : déterminer dans quelle mesure le produit en cours de développement répond aux attentes des utilisateurs, si nous allons dans la bonne direction, si nous déterminons correctement l'importance des fonctionnalités et choisissons les options de solution.

• Pour calculer cette métrique, nous menons également une enquête auprès des utilisateurs et calculons le score moyen. En calculant cet indicateur de manière régulière (par exemple après chaque sortie), vous pouvez suivre l'évolution de la satisfaction des utilisateurs.

3. Engagement des parties prenantes

Nombre d'initiatives et de propositions visant à améliorer le processus et le produit reçues au cours de l'itération (version) de la part des parties prenantes

Objectif métrique : déterminer le degré de participation des parties prenantes externes aux travaux sur le produit. Ayant une telle mesure en main, vous pouvez naviguer là où vous avez besoin d’obtenir des commentaires afin qu’un jour vous ne soyez pas confronté au mépris et à la haine, aux problèmes et aux malentendus.

Les méthodes quantitatives étant bien établies dans d’autres domaines, de nombreux théoriciens et praticiens de l’informatique ont tenté de les transférer cette approche et dans le développement de logiciels. Comme le disait Tom DeMarco : « Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer. »

Métrique

L'ensemble de métriques utilisées comprend :

• ordre de croissance (c'est-à-dire l'analyse des algorithmes en termes d'analyse asymptotique et de notation O),
• analyse des points de fonction,
• nombre d'erreurs pour 1000 lignes de code,
• degré de couverture du code par les tests,
• nombre de classes et d'interfaces,
• métriques du progiciel de Robert Cecil Martin,

Critique

Lacunes potentielles de l’approche ciblées par les critiques :

• Contraire à l'éthique : il est contraire à l'éthique de juger les performances d'un programmeur sur la base de mesures introduites pour évaluer les performances. code de programme. Des mesures aussi connues que le nombre de lignes de code et la complexité cyclomatique donnent souvent une idée superficielle du « succès » du choix d'une approche particulière pour résoudre des problèmes. Cependant, elles sont souvent considérées comme un outil d'évaluation de la qualité du travail d'un développeur. Cette approche conduit assez souvent à l’effet inverse, conduisant à l’apparition de constructions plus longues et de méthodes facultatives redondantes dans le code.
• Remplacer la « gestion des personnes » par une « gestion des chiffres », qui ne prend pas en compte l’expérience des salariés et leurs autres qualités
• Distorsion : Le processus de mesure peut être faussé du fait que les salariés ont connaissance des indicateurs mesurés et cherchent à optimiser ces indicateurs plutôt que leur performance. Par exemple, si le nombre de lignes du code source est un indicateur important, alors les programmeurs s'efforceront d'écrire autant de lignes que possible et n'utiliseront pas de techniques de simplification du code qui réduisent le nombre de lignes.
• Inexactitude : il n'existe pas de mesures suffisamment significatives et précises. Le nombre de lignes de code est simplement le nombre de lignes ; cet indicateur ne donne pas une idée de la complexité du problème à résoudre. L'analyse des points de fonction a été développée pour mieux mesurer la complexité du code et des spécifications, mais elle utilise le jugement personnel du mesureur, de sorte que différentes personnes obtiendront des résultats différents.

voir également

• Métriques de code de base : LOC, SLOC, Gilb, McCabe, Halstead, OOP et autres

Fondation Wikimédia. 2010.

• Odomètre
• Stéthoscope

Découvrez ce qu’est « Software Metrics » dans d’autres dictionnaires :

Qualité du logiciel

Estimation des coûts de développement de logiciels- Lors du développement de logiciels, le problème de l'estimation des coûts matériels et/ou du temps consacré à la réussite du projet est très important. Il existe de nombreuses méthodes pour effectuer une telle évaluation, parmi lesquelles les méthodes générales... ... Wikipédia

Métrique- a plusieurs significations : En mathématiques, la métrique est une fonction qui détermine les distances dans l'espace métrique. Métrique nom alternatif tenseur métrique, en particulier Tenseur métrique de l'espace-temps 4, qui... ... Wikipédia

Couverture de code- Ce terme a d'autres significations, voir Couverture. La couverture du code est une mesure utilisée dans les tests logiciels. Il montre le pourcentage auquel le code source du programme a été testé. La technique de couverture de code était... ... Wikipédia

Nombre de lignes de code- Voir aussi : Volume de code Source Lines of Code SLOC est une métrique logicielle utilisée pour mesurer son volume en comptant le nombre de lignes dans le texte du code source. En règle générale, ... ... Wikipédia

Tests de résistance- (eng. Load Testing) détermination ou collecte d'indicateurs de performance et de temps de réponse par programme système technique ou un appareil en réponse à une demande externe afin d'établir la conformité aux exigences d'un système donné... Wikipédia

Test de performance- Cet article manque de liens vers des sources d'informations. Les informations doivent être vérifiables, sinon elles pourraient être remises en question et supprimées. Vous pouvez... Wikipédia

Mêlée- Développement de logiciels Processus de développement de logiciels Étapes du processus Analyse Conception Programmation Document ... Wikipédia

Complexité cyclomatique- programmes (anglais : Cyclomatic complex of a program) mesure structurelle (ou topologique) de la complexité d'un programme, utilisée pour mesurer la qualité d'un logiciel, basée sur des méthodes d'analyse statique du code. DSP est égal à ... ... Wikipédia

Zabbix- 1.1 alpha 6 fonctionnant sous GNU/Linux... Wikipédia

En plus du SLOC, les caractéristiques quantitatives comprennent également :

• nombre de lignes vides,
• nombre de commentaires,
• pourcentage de commentaires (le rapport entre le nombre de lignes contenant des commentaires et le nombre total de lignes, exprimé en pourcentage),
• nombre moyen de lignes pour les fonctions (classes, fichiers),
• nombre moyen de lignes contenant le code source des fonctions (classes, fichiers),
• nombre moyen de lignes pour les modules.

Parfois, une distinction supplémentaire est faite entre la note stylistique du programme (F). Elle consiste à diviser le programme en n fragments égaux et à calculer l'estimation pour chaque fragment à l'aide de la formule F i = SIGN (Ncomm. i / N i - 0,1), où Ncomm. i - nombre de commentaires dans i-ème fragment, N i - le nombre total de lignes de code dans le i-ème fragment. Alors note globale pour l'ensemble du programme sera déterminé comme suit : F = SOMME F i .

Les métriques Halstead sont également incluses dans le groupe de métriques basées sur le comptage de certaines unités dans le code du programme. Ces mesures sont basées sur les indicateurs suivants :

N1 - nombre d'instructions de programme uniques, y compris les symboles

Séparateurs, noms de procédures et signes d'opération (dictionnaire opérateur),

N2 - nombre d'opérandes de programme uniques (dictionnaire d'opérandes),

N1 - le nombre total d'instructions dans le programme,

N2 - le nombre total d'opérandes dans le programme,

N1" - nombre théorique d'opérateurs uniques,

N2" est le nombre théorique d'opérandes uniques.

Compte tenu des notations introduites, on peut déterminer :

N=n1+n2 - dictionnaire du programme,

N=N1+N2 - durée du programme,

N"=n1"+n2" - dictionnaire théorique du programme,

N"= n1*log 2 (n1) + n2*log 2 (n2) - durée théorique du programme (pour les programmes stylistiquement corrects, l'écart de N par rapport à N" ne dépasse pas 10 %)

V=N*log 2 n - volume du programme,

V"=N"*log 2 n" est le volume théorique du programme, où n* est le dictionnaire théorique du programme.

L=V"/V - niveau de qualité de programmation, pour un programme idéal L=1

L"= (2 n2)/ (n1*N2) - niveau de qualité de programmation basé uniquement sur les paramètres vrai programme sans prendre en compte les paramètres théoriques,

E C =V/(L")2 - difficulté de compréhension du programme,

D=1/ L" - complexité du codage du programme,

Y" = V/ D2 - niveau de langage d'expression

I=V/D - contenu informatif du programme, cette caractéristique vous permet de déterminer les coûts mentaux de création d'un programme

E=N" * log 2 (n/L) - évaluation de l'effort intellectuel requis lors du développement d'un programme, caractérisant le nombre de solutions élémentaires requises lors de l'écriture d'un programme

Lors de l'utilisation des métriques Halstead, les inconvénients associés à la possibilité d'enregistrer la même fonctionnalité avec un nombre différent de lignes et d'opérateurs sont partiellement compensés.

Un autre type de métriques logicielles quantitatives sont les métriques Gilb. Ils montrent la complexité du logiciel basée sur la richesse du programme expressions conditionnelles ou des opérateurs de boucle. Cette métrique, malgré sa simplicité, reflète assez bien la complexité d'écriture et de compréhension d'un programme, et en ajoutant un indicateur tel que le niveau maximum d'imbrication des instructions conditionnelles et cycliques, l'efficacité de cette métrique augmente considérablement.

2. Mesures de la complexité du flux de contrôle du programme

La prochaine grande classe de métriques, basée non pas sur des indicateurs quantitatifs, mais sur l'analyse du graphique de contrôle du programme, est appelée métriques de complexité du flux de contrôle du programme.

Avant de décrire directement les métriques elles-mêmes, pour une meilleure compréhension, le graphe de contrôle du programme et la méthode pour le construire seront décrits.

Laissez un programme être présenté. Pour ce programme, un graphe orienté est construit contenant une seule entrée et une sortie, tandis que les sommets du graphe sont corrélés aux sections du code du programme dans lesquelles il n'y a que des calculs séquentiels et il n'y a pas d'opérateurs de branchement et de boucle, et le les arcs sont corrélés aux transitions de bloc en bloc et aux branches d'exécution du programme. Condition de construction de ce graphe : chaque sommet est accessible depuis le sommet initial, et le sommet final est accessible depuis n'importe quel autre sommet.

L'estimation la plus courante basée sur l'analyse du graphique résultant est la complexité cyclomatique du programme (nombre cyclomatique de McCabe). Il est défini comme V(G)=e - n + 2p, où e est le nombre d'arcs, n est le nombre de sommets, p est le nombre de composants connectés. Le nombre de composantes connectées d’un graphe peut être considéré comme le nombre d’arcs qui doivent être ajoutés pour transformer le graphe en un graphe fortement connecté. Un graphe est dit fortement connecté si deux sommets sont mutuellement accessibles. Pour les graphiques de programmes corrects, c'est-à-dire les graphiques qui n'ont pas de sections inaccessibles depuis le point d'entrée et qui n'ont pas de points d'entrée et de sortie « pendants », un graphique fortement connecté est généralement obtenu en fermant un arc à partir d'un sommet indiquant la fin de le programme à un sommet désignant le point d’entrée de ce programme. Essentiellement, V(G) détermine le nombre de circuits linéairement indépendants dans un graphe fortement connecté. Donc dans les programmes correctement écrits p=1, et donc la formule de calcul de la complexité cyclomatique prend la forme :

V(G)=e - n + 2.

Malheureusement, cette évaluation ne permet pas de distinguer les structures cycliques des structures conditionnelles. Un de plus inconvénient majeur Cette approche est que les programmes représentés par les mêmes graphes peuvent avoir des prédicats de complexité complètement différente (un prédicat est une expression logique contenant au moins une variable).

Pour corriger cette lacune, G. Myers a développé une nouvelle technique. Comme estimation, il a suggéré de prendre un intervalle (cette estimation est également appelée intervalle), où h pour les prédicats simples est égal à zéro, et pour les prédicats n-aires h = n-1. Cette méthode permet de distinguer des prédicats de complexité différente, mais en pratique elle n'est quasiment jamais utilisée.

Une autre modification de la méthode McCabe est la méthode Hansen. La mesure de la complexité du programme dans ce cas est représentée par une paire (complexité cyclomatique, nombre d'instructions). L'avantage de cette mesure est sa sensibilité à la structure du logiciel.

La mesure topologique de Chen exprime la complexité d'un programme en termes de nombre de franchissements de frontières entre les régions formées par le graphe du programme. Cette approche n'est applicable qu'aux programmes structurés qui permettent uniquement connexion série Structures de contrôle. Pour les programmes non structurés, la mesure de Chen dépend significativement des branches conditionnelles et inconditionnelles. Dans ce cas, vous pouvez spécifier les limites supérieure et inférieure de la mesure. Celui du haut est m+1, où m est le nombre d'opérateurs logiques avec leur imbrication mutuelle. Celle du bas est égale à 2. Lorsque le graphe de contrôle d'un programme ne comporte qu'une seule composante connexe, la mesure de Chen coïncide avec la mesure cyclomatique de McCabe.

Poursuivant le sujet de l'analyse du graphe de contrôle d'un programme, nous pouvons distinguer un autre sous-groupe de métriques - les métriques Harrison et Majel.

Ces mesures tiennent compte du niveau d'investissement et de la durée du programme.

Chaque sommet se voit attribuer sa propre complexité en fonction de l'opérateur qu'il représente. Cette complexité initiale des sommets peut être calculée de n’importe quelle manière, y compris en utilisant des mesures de Halstead. Pour chaque sommet de prédicat, nous sélectionnons un sous-graphe généré par les sommets qui sont les extrémités des arcs qui en émanent, ainsi que les sommets accessibles depuis chacun de ces sommets (la limite inférieure du sous-graphe) et les sommets qui se trouvent sur le chemins depuis le sommet du prédicat jusqu’à une limite inférieure. Ce sous-graphe est appelé la sphère d'influence du sommet du prédicat.

La complexité réduite d'un sommet prédicat est la somme des complexités initiales ou réduites des sommets inclus dans sa sphère d'influence, plus la complexité primaire du sommet prédicat lui-même.

La mesure fonctionnelle (SCOPE) d'un programme est la somme des complexités réduites de tous les sommets du graphe de contrôle.

La relation fonctionnelle (SCORT) est le rapport entre le nombre de sommets d'un graphe de contrôle et sa complexité fonctionnelle, et les sommets terminaux sont exclus du nombre de sommets.

SCORT peut prendre différentes valeurs pour les graphiques ayant le même numéro cyclomatique.

La métrique Pivovarsky est une autre modification de la mesure de complexité cyclomatique. Il vous permet de suivre les différences non seulement entre les structures de contrôle séquentielles et imbriquées, mais également entre les programmes structurés et non structurés. Elle s'exprime par la relation N(G) = v *(G) + SUMMAPi, où v *(G) est la complexité cyclomatique modifiée, calculée de la même manière que V(G), mais à une différence près : une instruction CASE avec n sorties est considéré comme un opérateur logique, pas comme n - 1 opérateurs.

Pi est la profondeur d'imbrication du i-ème sommet du prédicat. Pour calculer la profondeur d'imbrication des sommets du prédicat, le nombre de « sphères d'influence » est utilisé. La profondeur d'imbrication s'entend comme le nombre de toutes les « sphères d'influence » des prédicats qui sont soit entièrement contenues dans la sphère du sommet en question, soit qui la croisent. La profondeur de l'imbrication augmente en raison de l'imbrication non pas des prédicats eux-mêmes, mais des « sphères d'influence ». La mesure de Pivovarsky augmente lorsqu'on passe de programmes séquentiels à des programmes imbriqués puis à des programmes non structurés, ce qui constitue son énorme avantage par rapport à de nombreuses autres mesures de ce groupe.

Mesure de Woodward - le nombre d'intersections d'arcs du graphe de contrôle. Puisque de telles situations ne devraient pas se produire dans un programme bien structuré, cette métrique est principalement utilisée dans les langages faiblement structurés (Assembleur, Fortran). Un point d'intersection se produit lorsque le contrôle dépasse deux sommets qui sont des opérateurs séquentiels.

La méthode des valeurs limites repose également sur l’analyse du graphe de contrôle du programme. Pour définir cette méthode, il est nécessaire d’introduire plusieurs concepts supplémentaires.

Soit G le graphe de contrôle d'un programme avec un seul sommet initial et un seul sommet final.

Dans ce graphique, le nombre de sommets d'arcs entrants est appelé degré négatif du sommet, et le nombre d'arcs émanant du sommet est appelé degré positif du sommet. L’ensemble des sommets du graphe peut alors être divisé en deux groupes : les sommets de degré positif<=1; вершины, у которых положительная степень >=2.

Nous appellerons les sommets du premier groupe sommets de réception, et les sommets du deuxième groupe - sommets de sélection.

Chaque sommet de réception a une complexité réduite de 1, à l'exception du sommet d'extrémité, qui a une complexité réduite de 0. Les complexités réduites de tous les sommets de G sont additionnées pour former la complexité limite absolue du programme. Après cela, la complexité marginale relative du programme est déterminée :

Où S0 est la complexité marginale relative du programme, Sa est la complexité marginale absolue du programme, v est le nombre total de sommets du graphe du programme.

Il existe une métrique de Schneidewind, exprimée en termes de nombre moyens possibles dans le graphe de contrôle.

3. Mesures de complexité du flux de données

La classe suivante de métriques est celle des métriques de complexité du flux de contrôle des données.

Métrique Chapin : l'essence de la méthode est d'évaluer la force informationnelle d'un seul module logiciel en analysant la nature de l'utilisation des variables de la liste d'entrées-sorties.

L'ensemble des variables qui composent la liste d'E/S est divisé en 4 groupes fonctionnels :

1. P - variables d'entrée pour les calculs et pour fournir des sorties,

2. M - variables modifiées ou créées dans le programme,

3. C - variables impliquées dans le contrôle du fonctionnement du module logiciel (variables de contrôle),

Puisque chaque variable peut remplir plusieurs fonctions simultanément, elle doit être considérée dans chaque groupe fonctionnel correspondant.

Métrique Chapin :

Q = a1*P + a2*M + a3*C + a4*T,

Où a1, a2, a3, a4 sont des coefficients de pondération.

Q = P + 2M + 3C + 0,5T

La métrique d'étendue est basée sur la localisation des accès aux données au sein de chaque section du programme. Spen est le nombre d'instructions contenant un identifiant donné entre sa première et sa dernière apparition dans le texte du programme. Par conséquent, un identifiant qui apparaît n fois a une durée de n-1. Avec une grande étendue, les tests et le débogage deviennent plus compliqués.

Une autre métrique qui prend en compte la complexité d'un flux de données est une métrique qui relie la complexité des programmes aux accès aux variables globales.

Une paire module-variable globale est notée (p,r), où p est le module qui a accès à la variable globale r. Selon que le programme accède ou non à la variable r, deux types de couples « module - variable globale » se forment : réels et possibles. La référence possible à r par p montre que le domaine d'existence de r inclut p.

Cette caractéristique est notée Aup et indique combien de fois les modules Up ont réellement accédé aux variables globales, et le nombre Pup indique combien de fois ils auraient pu y accéder.

Le rapport entre le nombre d'appels réels et les appels possibles est déterminé

Cette formule montre la probabilité approximative qu'un module arbitraire fasse référence à une variable globale arbitraire. Évidemment, plus cette probabilité est élevée, plus la probabilité de modification « non autorisée » de toute variable est élevée, ce qui peut compliquer considérablement le travail associé à la modification du programme.

La mesure Kafur a été créée sur la base du concept de flux d'informations. Pour utiliser cette mesure, les notions de flux local et global sont introduites : un flux local d'informations de A vers B existe si :

1. Le module A appelle le module B (thread local direct)

2. Le module B appelle le module A et A renvoie à B une valeur utilisée dans B (flux local indirect)

3. Le module C appelle les modules A, B et transfère le résultat du module A vers B.

Ensuite, nous devrions donner le concept de flux d'informations global : un flux global d'informations de A vers B à travers une structure de données globale D existe si le module A met des informations dans D et si le module B utilise les informations de D.

Sur la base de ces concepts, la valeur I est introduite - la complexité informationnelle de la procédure :
I = longueur * (fan_in * fan_out)2
Ici:

Longueur - complexité du texte de la procédure (mesurée par l'une des métriques de volume, telles que les métriques Halstead, McCabe, LOC, etc.)

Fan_in - le nombre de threads locaux entrant dans la procédure plus le nombre de structures de données à partir desquelles la procédure prend des informations

Fan_out - le nombre de threads locaux émanant de la procédure plus le nombre de structures de données mises à jour par la procédure

La complexité informationnelle d'un module peut être définie comme la somme des complexités informationnelles des procédures qui y sont incluses.

L'étape suivante consiste à considérer la complexité des informations d'un module par rapport à une certaine structure de données. Mesure informative de la complexité du module par rapport à la structure des données :

J = W * R + W * RW + RW *R + RW * (RW - 1)

W est le nombre de procédures qui mettent uniquement à jour la structure des données ;

R - lit uniquement les informations de la structure de données ;

RW - lit et met à jour les informations dans la structure de données.

Une autre mesure de ce groupe est la mesure d'Oviedo. Son essence est que le programme est divisé en sections linéaires sans intersection - des rayons d'opérateurs qui forment le graphique de contrôle du programme.

L'auteur de la métrique fait les hypothèses suivantes : le programmeur peut trouver la relation entre la définition et l'utilisation des occurrences d'une variable au sein d'un rayon plus facilement qu'entre les rayons ; Le nombre d'occurrences de définition distinctes dans chaque rayon est plus important que le nombre total d'occurrences variables utilisant dans chaque rayon.

Notons R(i) l'ensemble des occurrences déterminantes de variables situées dans le rayon d'action du rayon i (une occurrence déterminante d'une variable est dans le rayon d'action d'un rayon si la variable y est locale et a une occurrence déterminante, ou pour cela il y a une occurrence déterminante dans un rayon précédent, et aucun définition locale le long du chemin). Notons V(i) l'ensemble des variables dont les occurrences sont déjà dans le rayon i. Alors la mesure de complexité du i-ème rayon est donnée comme suit :

DF(i)=SOMME(DEF(v j)), j=i...||V(i)||

Où DEF(v j) est le nombre d'occurrences déterminantes de la variable v j de l'ensemble R(i), et ||V(i)|| - puissance de l'ensemble V(i).

4. Mesures du flux de contrôle et de la complexité des données du programme

La quatrième classe de métriques est constituée de métriques proches à la fois de la classe des métriques quantitatives, de la classe des métriques de complexité du flux de contrôle de programme et de la classe des métriques de complexité du flux de contrôle de données (à proprement parler, cette classe de métriques et la classe de métriques de contrôle de programme). les métriques de complexité de flux sont de la même classe - métriques topologiques, mais il est logique de les séparer dans ce contexte pour plus de clarté). Cette classe de métriques établit la complexité de la structure du programme à la fois sur la base de calculs quantitatifs et sur la base d'une analyse des structures de contrôle.

La première de ces métriques est le test M-Measure. Une mesure de test M est une mesure de complexité qui satisfait aux conditions suivantes :

La mesure augmente avec la profondeur de nidification et prend en compte la durée du programme. Une mesure basée sur des intégrations régulières est étroitement liée à la mesure de test. L'idée de cette mesure de complexité du programme est de compter le nombre total de caractères (opérandes, opérateurs, parenthèses) dans une expression régulière avec le nombre minimum requis de parenthèses décrivant le graphe de contrôle du programme. Toutes les mesures de ce groupe sont sensibles à l’imbrication des structures de contrôle et à la durée du programme. Cependant, le niveau de complexité informatique augmente.

En outre, la cohérence des modules du programme est une mesure de la qualité du logiciel. Si les modules sont étroitement couplés, le programme devient alors difficile à modifier et à comprendre. Cette mesure n'est pas exprimée numériquement. Types de connectivité des modules :

Connectivité des données - si les modules interagissent par le transfert de paramètres et que chaque paramètre est un objet d'information élémentaire. Il s’agit du type de connexion (couplage) le plus préféré.

Connectivité par structure de données - si un module envoie à un autre un objet d'information composite (structure) pour l'échange de données.

Couplage de contrôle - si l'un envoie à un autre un objet d'information - un indicateur conçu pour contrôler sa logique interne.

Les modules sont liés par une zone commune s'ils font référence à la même zone de données globales. Le couplage sur une portée globale n'est pas souhaitable car, premièrement, un bogue dans un module qui utilise la portée globale peut apparaître de manière inattendue dans n'importe quel autre module ; Deuxièmement, ces programmes sont difficiles à comprendre, car il est difficile pour le programmeur de déterminer quelles données sont utilisées par un module spécifique.

Cohésion par le contenu - si l'un des modules est lié à un autre. Il s'agit d'un type de couplage inacceptable, car il contredit complètement le principe de modularité, c'est-à-dire représentation du module sous forme de boîte noire.

Couplage externe : deux modules partagent des données externes, telles qu'un protocole de communication.

La connectivité par messages est le type de connectivité le plus libre ; les modules ne sont pas directement connectés les uns aux autres ; ils communiquent via des messages qui n'ont pas de paramètres.

Manque de couplage - les modules n'interagissent pas les uns avec les autres.

Le couplage de sous-classes est une relation entre une classe parent et une classe enfant, dans laquelle l'enfant est lié au parent, mais le parent n'est pas lié à l'enfant.

Relation temporelle - deux actions sont regroupées dans un seul module uniquement parce que, en raison des circonstances, elles se produisent en même temps.

Une autre mesure liée à la stabilité d'un module est la mesure Colofello, elle peut être définie comme le nombre de modifications qui doivent être apportées à des modules autres que celui dont la stabilité est vérifiée, et ces modifications doivent concerner le module testé. .

La métrique suivante de cette classe est la métrique McClure. Il y a trois étapes dans le calcul de cette métrique :

1. Pour chaque variable de contrôle i, la valeur de sa fonction de complexité C(i) est calculée à l'aide de la formule : C(i) = (D(i) * J(i))/n.

Où D(i) est une valeur qui mesure la portée de la variable i. J(i) est une mesure de la complexité de l'interaction des modules via la variable i, n est le nombre de modules individuels dans le schéma de partitionnement.

2. Pour tous les modules inclus dans la sphère de partitionnement, la valeur de leurs fonctions de complexité M(P) est déterminée par la formule M(P) = fp * X(P) + gp * Y(P)
où fp et gp sont respectivement le nombre de modules précédant et suivant immédiatement le module P, X(P) est la complexité d'accès au module P,

Y(P) - complexité de l'appel du contrôle depuis le module P d'autres modules.

3. La complexité globale du schéma hiérarchique MP pour diviser un programme en modules est donnée par la formule :

MP = SUM(M(P)) sur toutes les valeurs possibles des modules de programme P.

Cette métrique se concentre sur les programmes bien structurés, composés de modules hiérarchiques qui définissent la spécification fonctionnelle et la structure de contrôle. On suppose également que chaque module a un point d'entrée et un point de sortie, que le module remplit exactement une fonction et que les modules sont appelés conformément à système hiérarchique contrôle, qui précise la relation d'appel sur un ensemble de modules de programme.

Il existe également une métrique basée sur le concept d'information, la mesure de Berlinger. La mesure de complexité est calculée comme M=SUMf i *log 2 pi , où fi est la fréquence d'apparition du i-ème symbole, pi est la probabilité de son apparition.

L’inconvénient de cette métrique est qu’un programme contenant de nombreux caractères uniques, mais en petite quantité, aura la même complexité qu’un programme contenant un petit nombre de caractères uniques, mais en grande quantité.

5. Métriques orientées objet

Avec le développement des langages de programmation orientés objet, une nouvelle classe de métriques est apparue, également appelées métriques orientées objet. Dans ce groupe, les plus couramment utilisés sont l’ensemble de métriques Martin et l’ensemble de métriques Chidamber et Kemerer. Examinons d’abord le premier sous-groupe.

Avant de commencer à considérer les métriques de Martin, il est nécessaire d’introduire la notion de catégorie de classe. En réalité, une classe peut rarement être réutilisée indépendamment des autres classes. Presque chaque classe possède un groupe de classes avec lesquelles elle travaille en coopération et dont elle ne peut pas être facilement séparée. Pour réutiliser de telles classes, vous devez réutiliser l'ensemble du groupe de classes. Un tel groupe de classes est fortement connecté et est appelé une catégorie de classes. Pour l'existence d'une catégorie de classe, les conditions suivantes existent :

Les classes au sein d’une catégorie de classe sont protégées de toute tentative de les modifier toutes ensemble. Cela signifie que si une classe devait changer, toutes les classes de cette catégorie seraient susceptibles de changer. Si l’une des classes est ouverte à un certain type de changement, elles sont toutes ouvertes à ce type de changement.

Les classes d'une catégorie ne sont réutilisées qu'ensemble. Ils sont tellement interdépendants qu’ils ne peuvent être séparés les uns des autres. Ainsi, si l'on tente de réutiliser une classe dans une catégorie, toutes les autres classes doivent être réutilisées avec elle.

La responsabilité, l'indépendance et la stabilité d'une catégorie peuvent être mesurées en comptant les dépendances qui interagissent avec cette catégorie. Trois métriques peuvent être définies :

1. Ca : Cohésion centripète. Le nombre de classes en dehors de cette catégorie qui dépend des classes à l'intérieur de cette catégorie.

2. Ce : Embrayage centrifuge. Nombre de classes au sein de cette catégorie qui dépendent des classes en dehors de cette catégorie.

3. I : Instabilité : I = Ce / (Ca+Ce). Cette métrique a une plage de valeurs.

I = 0 indique la catégorie la plus stable.

I = 1 indique la catégorie la plus instable.

Vous pouvez définir une métrique qui mesure le caractère abstrait (si une catégorie est abstraite, alors elle est suffisamment flexible et peut être facilement étendue) d'une catégorie comme suit :

A : Abstraction : A = nA / nAll.

NA - number_of_abstract_classes_in_category.

NAll - total_number_of_classes_in_category.

Les valeurs de cette métrique varient dans la plage.

Désormais, sur la base des métriques Martin ci-dessus, vous pouvez créer un graphique qui montre la relation entre abstraction et instabilité. Si nous construisons dessus une ligne droite, donnée par la formule I+A=1, alors cette ligne droite contiendra les catégories qui ont le meilleur équilibre entre abstraction et instabilité. Cette ligne est appelée la séquence principale.

Distance à la séquence principale : D=|(A+I-1)/sqrt(2)|

Distance normalisée à la séquence principale : Dn=|A+I-2|

Il est vrai pour presque toutes les catégories que plus elles sont proches de la séquence principale, mieux c'est.

Le sous-groupe suivant de métriques est celui de Chidamber et Kemerer. Ces métriques sont basées sur l'analyse des méthodes de classe, de l'arbre d'héritage, etc.

WMC (Méthodes pondérées par classe), la complexité totale de toutes les méthodes de la classe : WMC=SUMAc i , i=1...n, où c i est la complexité de la i-ème méthode, calculée à l'aide de l'une des métriques ( Halstead, etc. en fonction du critère d'intérêt), si toutes les méthodes ont la même complexité, alors WMC=n.

DIT (Depth of Inheritance tree) - la profondeur de l'arbre d'héritage (le chemin le plus long le long de la hiérarchie des classes jusqu'à une classe donnée à partir de la classe ancêtre), plus elle est grande, mieux c'est, car avec une plus grande profondeur l'abstraction des données augmente, la saturation de la classe avec les méthodes diminue, mais avec une profondeur suffisamment grande, la complexité de compréhension et d'écriture d'un programme augmente considérablement.

NOC (Nombre d'enfants) - le nombre de descendants (immédiat), plus l'abstraction des données est élevée.

CBO (Couplage entre classes d'objets) - couplage entre classes, affiche le nombre de classes auxquelles la classe d'origine est associée. Pour cette métrique, toutes les déclarations introduites précédemment pour la connectivité des modules sont valables, c'est-à-dire qu'avec un CBO élevé, l'abstraction des données diminue et la réutilisation des classes devient plus difficile.

RFC (Réponse pour une classe) - RFC=|RS|, où RS est l'ensemble de réponses d'une classe, c'est-à-dire l'ensemble des méthodes qui peuvent potentiellement être appelées par une méthode de classe en réponse aux données reçues par un objet de la classe. classe. Autrement dit, RS=(((M)((R i )), i=1...n, où M sont tous méthodes possibles classe, R i - toutes les méthodes possibles qui peuvent être appelées par la i-ème classe. Alors RFC sera la cardinalité de cet ensemble. Plus il y a de RFC, plus il est difficile de tester et de déboguer.

LCOM (Manque de cohésion dans les méthodes) - manque de cohésion des méthodes. Pour déterminer ce paramètre, considérons la classe C avec n méthodes M1, M2,… ,Mn, alors (I1),(I2),...,(In) sont des ensembles de variables utilisés dans ces méthodes. Nous définissons maintenant P - un ensemble de paires de méthodes qui n'ont pas de variables communes ; Q est un ensemble de paires de méthodes ayant des variables communes. Alors LCOM=|P|-|Q|. Le manque de cohésion peut indiquer que la classe peut être divisée en plusieurs autres classes ou sous-classes. Il est donc préférable d'augmenter la cohésion pour augmenter l'encapsulation des données et réduire la complexité des classes et des méthodes.

6. Mesures de fiabilité

Le type de métriques suivant est celui des métriques proches des quantitatives, mais basées sur le nombre d'erreurs et de défauts dans le programme. Cela ne sert à rien de considérer les caractéristiques de chacune de ces métriques, il suffira simplement de les lister : le nombre de modifications structurelles apportées depuis le dernier contrôle, le nombre d'erreurs identifiées lors de la revue de code, le nombre d'erreurs identifiées lors du programme tests et le nombre de changements structurels nécessaires requis pour bon fonctionnement programmes. Pour les grands projets, ces indicateurs sont généralement considérés par rapport à des milliers de lignes de code, c'est-à-dire nombre moyen de défauts pour mille lignes de code.

7. Métriques hybrides

Enfin, il faut mentionner une autre classe de métriques appelées hybrides. Les métriques de cette classe sont basées sur des métriques plus simples et représentent leur somme pondérée. Le premier représentant de cette classe est la métrique Kokol. Il est défini comme suit :

H_M = (M + R1 * M(M1) +… + Rn * M(Mn)/(1 + R1 +… + Rn)

Où M est la métrique de base, Mi sont d'autres mesures intéressantes, Ri sont des coefficients correctement sélectionnés, M(Mi) sont des fonctions.

Les fonctions M(Mi) et les coefficients Ri sont calculés à l'aide d'une analyse de régression ou d'une analyse de problème spécifique au programme.

La métrique de Zolnovsky, Simmons, Thayer est également une somme pondérée de divers indicateurs. Il existe deux options pour cette métrique :

(structure, interaction, volume, données) SOMME(a, b, c, d).

(complexité de l'interface, complexité informatique, complexité des E/S, lisibilité) SUM(x, y, z, p).

Les métriques utilisées dans chaque option sont sélectionnées en fonction de tâche spécifique, coefficients - en fonction de la valeur de la métrique pour prendre une décision dans un cas donné.

Conclusion

Pour résumer, je voudrais souligner qu’il n’existe pas une seule mesure universelle. Toutes les caractéristiques métriques surveillées du programme doivent être surveillées soit en fonction les unes des autres, soit en fonction de la tâche spécifique ; de plus, des mesures hybrides peuvent être utilisées, mais elles dépendent également de métriques plus simples et ne peuvent pas non plus être universelles. À proprement parler, toute métrique n’est qu’un indicateur qui dépend fortement du langage et du style de programmation, donc aucune mesure ne peut être élevée au rang d’absolu et aucune décision ne peut être prise uniquement sur cette base.