Parfois, on nous pose une question sur la valeur monétaire que l'entreprise recevra de l'utilisation de PVS-Studio. Nous avons décidé de rédiger une réponse sous forme d'article et de fournir des tableaux qui montreront comment l'analyseur peut être utile. Nous ne pouvons pas prouver l'exactitude absolue de tous les calculs dans l'article, mais nous supposons que le lecteur sera d'accord avec nos pensées, et cela aidera à prendre une décision en matière d'obtention de la licence.
Nous avons d'abord voulu mettre en place un ROI-Calculator sur le site et publier une description détaillée de ses principes de fonctionnement. Cependant, après avoir préparé une description, il est devenu clair que la calculatrice n'est pas nécessaire. Les tableaux donnés dans la description sont suffisants. Nous avons donc simplement rédigé cette explication comme un article que vous lisez en ce moment. J'espère que cela vous aidera à réaliser pleinement la rationalité de l'utilisation régulière de l'analyseur de code statique PVS-Studio.
PVS-Studio est un outil conçu pour détecter les erreurs et les vulnérabilités potentielles dans le code source des programmes, écrit en C, C ++, C # et Java. Il fonctionne dans un environnement Windows, Linux et macOS.
Calculons le retour sur investissement de l'utilisation de l'analyseur de code statique PVS-Studio au cours du développement - d'abord en "mode sceptique", puis plus réaliste.
La valeur de l'heure de travail d'un développeur
Pour déterminer combien d'argent PVS-Studio retournera, nous devons d'abord compter quel est le coût (valeur) réel de l'heure de travail d'un développeur.
Le fait est qu'il ne suffit pas de prendre le salaire annuel d'un développeur et de le diviser par 1900 heures de travail. Par ailleurs, le nombre 1900 est choisi plutôt arbitraire. Le nombre d'heures de travail par an dépend fortement du pays. Par exemple, en Corée du Sud dans l'année, il y a 2069 heures de travail, en Russie - 1974, aux États-Unis - 1783 et au Royaume-Uni - 1676. Néanmoins, le nombre 1900 est tout à fait approprié en termes de semaine de travail de 40 heures, et nous utiliserons exactement ce nombre pour d'autres calculs.
Alors, pourquoi ne suffit-il pas de diviser le salaire annuel par 1900?
Premièrement, les programmeurs, comme tout autre employé de n'importe quelle sphère, gagnent beaucoup plus d'argent qu'ils n'en reçoivent avec leur salaire, sinon l'entreprise sera déficitaire. Les programmeurs doivent disposer d'un espace de travail, d'Internet et de cookies, vous devez également payer le loyer, etc. Oh, oui, il y a encore des récompenses financières, des événements d'entreprise, divers bonus.
Avec tout cela, un développeur doit être rentable, ce qui signifie qu'il doit rapporter un bénéfice net à l'entreprise directement ou indirectement. En pratique, cela signifie que le travail d'un développeur, selon la situation, rapporte de 2 à 10 fois plus d'argent qu'il n'est dépensé pour son salaire. Il est important de souligner que les développeurs ne sont pas différents des autres employés salariés. Il y a certaines particularités liées à l'externalisation, mais c'est une autre histoire.
Pour les lecteurs sceptiques, nous prendrons le multiplicateur 2. Ce qui signifie qu'un développeur rapporte 2 fois plus d'argent qu'il n'en dépense pour son salaire. En fait, l'entreprise avec de tels multiplicateurs est au bord du seuil de rentabilité. Une approche plus honnête consiste à prendre un multiplicateur égal à au moins 3.
Qu'est-ce que tout cela signifie? Si un programmeur est tombé hors du processus de développement pendant 1 heure, l'entreprise n'a pas perdu une somme d'argent égale à une heure de son travail, mais en 2 ou 3 fois plus.
Il existe un deuxième facteur c qui influence le prix de l'heure de travail actuelle. Le fait est qu'un employé ne code pas 8 heures par jour. Il est inconcevable qu'un homme vienne tout juste le matin et s'occupe du code pendant 8 heures tout au long de la journée de travail. Un développeur travaille avec Trello, participe à des réunions, répond aux lettres par courrier, participe à la révision du code. En fin de compte, il doit aller aux toilettes et prendre le thé :). Dans le meilleur des cas, il travaillera directement avec le code pendant 6 heures. Si vous lisez ce texte pas en "mode sceptique", vous comprenez ce qui est en réalité 4 heures beaucoup plus plausible.
Il s'avère que le coût d'une heure doit être multiplié par 8/6 = 1,33 (mode sceptique) ou 8/4 = 2 (plus proche de la réalité).
Multiplions maintenant les deux multiplicateurs discutés et obtenons le multiplicateur final, par lequel vous devez multiplier le coût d'une heure d'un développeur:
- un multiplicateur pour les sceptiques: 2 * 1,33 = 2,66
- un multiplicateur, plus proche de la réalité: 3 * 2 = 6
En pratique, les coefficients seront un peu plus importants, car nous ne prenons pas en compte les vacances dans les calculs.
Voyons maintenant ce que cela signifie pour l'entreprise lorsqu'un développeur avec un salaire moyen de 74 000 $ par an se retire d'un flux de travail pendant 1 heure. Le gain annuel de 74000 $ a été choisi en fonction du salaire moyen en Allemagne selon les données du portail StepStone pour l'année 2018.
Remarque Pour une meilleure compréhension, il convient de noter qu'en fait, l'entreprise peut dépenser plus de 74 000 $ en salaires. Il convient de noter que l'entreprise peut verser des contributions aux différents fonds et payer des impôts différents. Cependant, cela dépend tellement des pays et des régimes fiscaux que nous n'essaierons même pas d'envisager toutes ces options. Par souci de simplicité, supposons que l'entreprise ne supporte aucun coût supplémentaire et dépense sur le salaire d'un développeur seulement 74 000 $ par an. Nous avons décidé de le noter, que nous arrondissons les chiffres qui ne sont pas en faveur de PVS-Studio.
Si le salaire est de 74 000 $, le taux horaire sera de 74 000 $ / 1900 = 39 $. Il s'avère que si un développeur est distrait en corrigeant une erreur pendant 1 heure, l'entreprise ne pourra pas gagner:
- pour les sceptiques: 39 $ / heure * 2,66 = 103 $ / heure
- en réalité plus de: 39 $ / heure * 6 = 234 $ / heure
Il s'agit du coût réel en heures-homme (la valeur de) une heure d'un développeur lorsqu'il fait quelque chose d'utile.
Combien d'heures PVS-Studio économise
Il est très difficile de dire avec certitude combien d'heures par an PVS-Studio économisera lors de la recherche d'erreurs dans les premiers stades. Les erreurs peuvent être très différentes. Un développeur peut remarquer lui-même certains d'entre eux et les corriger immédiatement. Néanmoins, un bug peut parfois distraire un développeur d'activités utiles pendant
quelques jours .
Sur la base de considérations empiriques pour les sceptiques, disons que l'analyseur économisera au moins 2 heures de travail d'un développeur par semaine, le libérant de la nécessité de rechercher les bogues détectés par les tests unitaires ou un service de test. Oui, la correction d'un bug lui-même prend généralement quelques minutes, mais en ce qui concerne les tentatives de reproduction du problème, les conversations dans un bugtracker, les tests, les fusions et ainsi de suite, cela prendra facilement ces 2 heures.
Deux heures mentionnées ci-dessus est une option sceptique, en fait cela peut prendre beaucoup plus. En gardant à l'esprit que parfois l'analyseur peut empêcher les
heisenbugs reproductibles
durs , la valeur moyenne peut être définitivement définie comme 3 heures.
Il y a environ 50 semaines dans une année. Pendant un an, l'analyseur enregistre le nombre d'heures de travail réel du développeur suivant:
- attitude sceptique face à l'analyse statique: 2 heures * 50 = 100 heures enregistrées
- attitude positive: 3 heures * 50 = 150 heures économisées
Il est temps de compter le ROI
Ensuite, en utilisant PVS-Studio, un programmeur avec un salaire de 74 000 $ reviendra à l'entreprise chaque année:
- Si vous êtes sceptique: 103 $ / heure * 100 heures = 10 300 $
- Réalité: 234 $ / heure * 150 heures = 35 100 $.
Prenons maintenant une équipe typique de 10 personnes. Après avoir introduit PVS-Studio, nous pouvons nous attendre à ce que, grâce au gain de temps, l'équipe puisse effectuer un travail utile qui coûtera:
- Sceptique: 103 000 $
- Réalité: 351 000 $
La formule finale
Alors, réunissons maintenant tout cela dans une seule formule.
Désignons le salaire annuel d'un programmeur par S.
Le nombre de développeurs dans une équipe est N.
- La formule pour un sceptique: N * (S / 1900) * 2,66 * 100
- La vraie formule: N * (S / 1900) * 6 * 150
Comment nous citerons les calculs pour les équipes avec un nombre différent de développeurs dans les tableaux. Le tableau montre le montant d'argent projeté qu'une équipe de développeurs peut faire pour une entreprise si, au cours de l'année au lieu de modifier des bogues, elle sera occupée à créer quelque chose de nouveau. Ce sont les chiffres qu'il faut comparer avec le prix de la licence.
Description du tableau. Rangée du haut: salaire du développeur par an. Colonne de gauche: nombre de programmeurs dans une équipe. Cellule de tableau: combien d'argent l'équipe gagnera-t-elle en plus au cours de l'année si, au lieu d'éditer des bugs (que le PVS-Studio peut trouver), l'équipe sera occupée par une programmation utile.
Table pour les sceptiques:
Tableau N1. Sceptique. Rouge: l'utilisation de PVS-Studio peut être déraisonnable. Vert: l'utilisation de l'analyseur statique est justifiée et utile. Bleu: l'utilisation est particulièrement bénéfique.Le tableau actuel:
Tableau N2. La réalité Rouge: l'utilisation de PVS-Studio peut être déraisonnable. Vert: l'utilisation de l'analyseur statique est justifiée et utile. Bleu: l'utilisation est particulièrement bénéfique.À notre avis, le deuxième tableau est valide et il est raisonnable d'en tenir compte lors de l'évaluation de la faisabilité de l'acquisition de la licence.
Remarque
Bien sûr, les calculs donnés ne conviennent pas toujours et pas partout. Par exemple, si le prix des bogues et des vulnérabilités du projet est extrêmement élevé, il n'y a aucune raison de lier la valeur de l'utilisation de PVS-Studio aux salaires. Dans de tels projets, il convient d'évaluer les éventuelles pertes monétaires et de réputation et de les associer à la réduction du risque lors de l'utilisation d'un analyseur de code. C'est sa propre histoire, et nous ne savons pas encore comment l'aborder du point de vue des calculs.
De plus, les calculs peuvent ne pas fonctionner pour les sociétés d'externalisation. Cela peut ne pas sembler très beau, mais ces sociétés sont intéressées à vendre autant d'heures que possible sur le développement, les tests et la maintenance. Dans un certain sens, l'utilisation de l'analyseur peut même réduire leurs gains. Ceci est indirectement confirmé par le fait que parmi les clients de PVS-Studio il n'y a pas de sociétés d'externalisation. De plus, à première vue, dans ces entreprises, des processus étranges peuvent se produire. En période de moindre activité, l'entreprise peut prendre un projet même à perte. C'est mieux que de dissoudre certains développeurs en vacances. Ils préfèrent être occupés avec quelque chose.
Conclusion
Ainsi, même si les calculs peuvent ne pas convenir à toutes les entreprises, nous espérons avoir réussi à montrer comment aborder l'évaluation de l'efficacité de l'utilisation de PVS-Studio en termes de business dans son ensemble.