Analyse comparative des logiciels

Benchmarks logiciels pour la prévisibilité des projets

Vous souhaitez comparer vos performances avec celles des autres, en interne ou par rapport aux équipes d'autres organisations. Pour les comparaisons entre les équipes internes, vous pouvez établir vos propres références internes, tandis que pour comparer avec d'autres équipes du secteur du logiciel, vous rechercherez des références en matière de logiciels de l'industrie. Cet article se concentre sur analyse comparative appropriée du travail logiciel afin que vous puissiez comparer les performances de vos équipes avec celles des autres. 

Nb. Cet article ne concerne pas l’analyse comparative des performances (vitesse) des logiciels.

L'analyse comparative des logiciels peut aider les organisations à comprendre leurs performances et les domaines dans lesquels elles pourraient chercher à s'améliorer. Grâce également aux benchmarks, les managers peuvent répondre aux questions vitales sur un projet logiciel de "Combien de temps cela prendra-t-il?" et "Combien cela coûtera-t-il?"   Les benchmarks peuvent également être utilisés pour aider à prendre des décisions commerciales précieuses sur les logiciels sur lesquels se concentrer.

Arrière-plan

Les logiciels deviennent un différenciateur clé entre les entreprises qui réussissent et celles qui échouent dans la plupart des secteurs. La capacité à produire des fonctionnalités logicielles innovantes et différenciantes de haute qualité plus rapidement que ses concurrents est l’une des clés pour qu’une entreprise batte ses concurrents. À terme, cela pourrait devenir un facteur majeur de survie des entreprises, ce qui est déjà le cas pour les entreprises technologiques.

Il devient de plus en plus important de connaître les performances de votre entreprise par rapport aux autres en termes de capacité à fournir des fonctionnalités logicielles. C’est là qu’intervient le benchmarking.

Analyse comparative de la productivité des développeurs

L'accent a tendance à être mis sur productivité des développeurs, plutôt pour trois raisons :

1. Variable. La productivité des développeurs varie considérablement : les plus qualifiés étant 100 fois plus productifs que les moins expérimentés.
2. Significatif. Le coût du développeur est généralement l’élément de coût le plus important de la fourniture d’un logiciel.
3. Précieux. Les entreprises dépendent de la fourniture de logiciels pour rester compétitives. La rapidité avec laquelle ils peuvent être livrés est donc importante pour une organisation.

La mesure de base de la production est la taille fonctionnelle, mais n'ignorez pas la qualité.

La mesure de base la plus utile de la production est la quantité de fonctionnalité reconnaissable par l'utilisateur qui peut être livré avec une haute qualité par un développeur ou par une équipe de développement. La meilleure façon de le déterminer n’est pas de compter les lignes de code, mais plutôt de déterminer la taille fonctionnelle du logiciel fourni. La taille fonctionnelle est mesurée à l’aide de la norme ISO COSMIC Function Point (CFP). Le CFP est la mesure standard la plus moderne et universelle pour la taille des logiciels. Il s'agit d'une mesure indépendante de la technologie de la taille reconnaissable par l'utilisateur. La productivité des développeurs et des équipes de développement peut être comparée en CFP moyen par mois ou en CFP moyen par sprint.

Benchmarks de productivité des développeurs

Chaque développeur ou équipe peut être comparé CFP par sprint.

Avertissement: Les mesures de productivité doivent exiger que la qualité soit vérifiée.

Ce sont des valeurs observées par l'auteur sur des dizaines de projets de taille modeste (250-1500 CFP). Vous devez établir et maintenir vos propres critères de référence. Ils sont souvent également exprimés sous la forme inverse, CFP délivrée par unité de temps. Par exemple. 20 CFP par mois.

Règle générale : 10 à 20 CFP par développeur et par mois est une règle générale. La plage de productivité observée des développeurs est de 2 à 200 CFP par développeur et par mois, en fonction des circonstances, du domaine, des outils et des compétences.

Benchmarks de productivité des équipes

Un guide général est que dans une équipe de sept personnes, 4 développeurs, 2 testeurs et un analyste commercial produiront en moyenne à raison de 4 heures par CFP, c'est-à-dire. 80 CFP par sprint de 2 semaines. Cela peut être réduit s'il y a un report de bugs à corriger des sprints précédents.

Règle générale : 70 CFP par sprint est une première estimation raisonnable, mais vous devez établir vos propres références.

La plupart des managers souhaitent savoir comment leur équipe et leur entreprise se comparent aux autres sur :

• Productivité du développement logiciel
• Qualité du logiciel
• Dépenses en logiciels
• Logiciel rapport qualité/prix

L'analyse comparative des logiciels internes compare différentes équipes ou projets au sein d'une organisation. L'analyse comparative des logiciels externes ou industriels compare ces caractéristiques aux normes externes.

Cet article explore quelles métriques logicielles peuvent être comparées et quelles métriques utiliser pour ne pas provoquer de conséquences involontaires.

Les valeurs de référence réelles présentées sont à titre indicatif uniquement et ne doivent pas être considérées comme des références définitives. Dans tous les cas, les références internes sont les meilleures, compilées à partir de travaux antérieurs au sein de votre organisation.

L’IA n’a pas été utilisée pour écrire cet article.

Benchmarks de ressources logicielles

Pour la planification d'équipe, les dirigeants doivent savoir quel est le quantité de travail idéale qu'une personne peut gérer. Les logiciels sont un travail de connaissances et les contraintes cognitives des développeurs sont telles qu'ils ne peuvent raisonnablement gérer qu'un certain nombre de fonctionnalités. Nos observations sont que cela tourne autour de 150 CFP. Ce qui signifie que quelle que soit la taille de votre projet, vous aurez probablement besoin de plus d'un développeur si votre périmètre total est supérieur à 180 CFP. Le tableau ci-dessous est une ligne directrice pour la capacité typique par rôle.

Par exemple, un projet de 1000 CFP nécessitera 1 chef de projet, 2 business analysts, 3 testeurs et 5 développeurs. Ces chiffres dépendent des compétences et des connaissances du domaine des personnes impliquées. Dans la mesure du possible, il est préférable de s’efforcer de constituer des équipes plus petites composées de personnes hautement compétentes.

Notez que pour les travaux de maintenance logicielle, un seul développeur peut généralement gérer plus de 180 CFP. Habituellement, la maintenance nécessite 1 développeur à temps plein pour 1 500 à 2 500 CFP.

Benchmarks de qualité des logiciels

La qualité des logiciels est une question d'avantage commercial. L’organisation qui fournit systématiquement des logiciels de qualité utiles aux clients est susceptible de surpasser ses concurrents. L’analyse comparative des mesures de qualité des logiciels devient donc un comparateur important pour les entreprises.

Potentiels de défauts

Le nombre de défauts dans un logiciel peut être anticipé. Les défauts peuvent être prédits en fonction de la taille du logiciel. Il va de soi qu’un logiciel plus gros peut potentiellement être plus bogué qu’un petit logiciel. Le potentiel de défaut est le concept du nombre de défauts susceptibles de se trouver dans un logiciel avant que nous commencions toute mesure de détection/évitement/suppression de défauts.

Les potentiels de défauts typiques sont de 4 à 5 défauts par CFP. Ces défauts varient en gravité et en origine. Généralement comme suit :

Source : Capers Jones, L'économie de la qualité des logiciels, 2011.

Cela signifie qu'il y aura probablement 5 défauts par CFP à moins que nous prenions des mesures d'amélioration de la qualité pour trouver et corriger les défauts dans chacun de ces domaines.

La prise de conscience des défauts potentiels aide à répondre à ces questions :

• Combien de défauts devons-nous détecter pour obtenir une qualité raisonnable ?
• Combien de défauts sont susceptibles d’être en suspens ?
• Combien de tests supplémentaires devons-nous effectuer ?
• Sommes-nous prêts à passer en direct ?

Efficacité de suppression des défauts

La qualité d'un produit logiciel est généralement observée comme le nombre de défauts exposés lors de la production. Le nombre de « nouveaux » défauts diminue au cours des 3 premiers mois, on peut donc dire que le L'efficacité de l'élimination des défauts est déterminée par le nombre de défauts détectés au cours des 3 premiers mois d'utilisation, exprimé en pourcentage des défauts potentiels, basé sur la quantité de fonctionnalités fournies.

Analyse comparative des logiciels – Calendriers

Le calendrier, ou le temps nécessaire pour livrer le logiciel, est une conséquence directe de la productivité de la ou des équipes travaillant sur le logiciel. Nous avons examiné la productivité des développeurs en termes de production d'équipe par sprint à environ 70 CFP par sprint de deux semaines, soit 140 par mois. Cela nous donne un guide clair pour répondre à la question. "Quand sera-t-il prêt?"

Règle générale : Pour les petits projets de moins de 1000 CFP : une équipe livrera généralement 140 CFP par mois.

Règle générale : Pour les grands projets de plus de 1000 CFP+, la productivité diminue avec la taille : le nombre de mois pour livrer = CFP ^ 0,4

Notez que fournir des fonctionnalités de mauvaise qualité ralentira globalement le projet. Ce n'est qu'avec une qualité élevée que les plannings les plus rapides peuvent être atteints.

Conseil: Si un CFP a été livré mais qu'un défaut est découvert lors d'un sprint ultérieur, vous ne le comptez pas comme livré.

Analyse comparative de la valeur délivrée

Si une entreprise dépense $1000 pour fournir 1 CFP de nouvelle fonctionnalité. La valeur commerciale globale de cette fonctionnalité devrait dépasser le coût du $1000 à court et à long terme. La valeur par CFP varie, mais les entreprises devraient penser à un retour sur valeur sur 1 à 3 ans en termes de plusieurs fois le coût par CFP. Le bénéfice commercial sur 3 ans par CFP est une mesure utile à suivre et peut être comparée.

Coût total de possession

Au-delà du coût initial de construction d'un CFP $1000, les entreprises doivent prendre en compte le coût total de possession sur la durée de vie de ce logiciel. Par exemple, au cours des deux premières années suivant la construction initiale, des améliorations considérables seront probablement apportées, environ 201 TP3T la première année et 151 TP3T supplémentaires la seconde suivante, soit généralement 81 TP3T par an. Vous pouvez établir vos propres références en interne pour le TCO des applications logicielles de votre portefeuille, ces données vous aideront à prendre des décisions concernant les plans de remplacement du système.

Règle générale: le coût total de possession total sur 5 ans est généralement de 2 à 3 fois le coût initial.

Modification de la portée de l'analyse comparative

Au cours d'un projet, de nouvelles exigences surgiront ou deviendront apparentes. Bien qu’une partie de ces informations soit connue dès le départ, d’autres ne le sont pas. Les organisations qui dépensent suffisamment pour le travail sur les exigences (15% ou plus pour le développement personnalisé, plus élevé pour les implémentations de packages tels que les ERP) obtiendront non seulement des délais plus courts, mais connaîtront également moins de changements de portée au cours du projet. Câpres Jones

Règle générale : Changement de périmètre 1-2% par mois au cours d'un projet.

Règle générale : 8% par an, changement de périmètre après la mise en œuvre.

 

Analyse comparative de la dette technique

La dette technique est la refonte qui découle de l'émergence d'exigences qui n'étaient pas connues lors de la première rédaction du code. Pour quantifier et comparer la dette technique, il faut d’abord classer soigneusement les retouches provoquées par :

• Erreurs de code (pas de dette technique)
• Raccourcis conçus pour un déploiement rapide (pas de dette technique dans le concept original mais généralement considéré comme tel)
• Retravailler car un travail sur les exigences insuffisant a été effectué (inconnues connaissables survenant plus tard). Il s’agit d’une dette technique évitable.
• Retravailler car des exigences sont apparues plus tard et n'étaient pas connaissables auparavant. (C’est la véritable dette technique inévitable.)

La plupart des organisations ne correspondent pas aux classifications ci-dessus et auront donc du mal à évaluer la dette technique.

 

Coût total de possession

Au-delà du coût initial de construction du $1000, les entreprises doivent prendre en compte le coût total de possession sur la durée de vie de ce logiciel. Au cours des deux premières années suivant la construction initiale, des améliorations considérables seront probablement apportées, environ 201 TP3T la première année et 151 TP3T supplémentaires la deuxième et 81 TP3T par la suite. Au-delà de cela, il y a la maintenance annuelle du logiciel, soit pour le faire fonctionner sur une infrastructure en constante évolution, soit pour corriger les bugs qui apparaissent. Câpres Jones

Règle générale: le coût sur 5 ans est généralement 3x le coût initial.

Autres références pour le travail logiciel

Ingénieurs par client/utilisateur

Ce numéro est souvent cité par les produits Saas grand public tels que Facebook et Twitter. Le plus souvent, il est exprimé en milliers d'utilisateurs par ingénieur. Il s’agit d’une mesure utile pour de telles organisations.

Revenu par ingénieur DevOps

Dans les entreprises à forte intensité logicielle, où le personnel technique constitue l'un des principaux coûts de l'entreprise, le suivi des revenus globaux par ingénieur DevOps est un indicateur général de l'efficacité technique.

DORA Métriques

Fréquence de déploiement

Est une mesure du nombre de fois où un nouveau code (de n’importe quelle quantité) est mis en production. Il s’agit d’un indicateur ponctuel utile de la répétabilité du cycle de développement/test. Une fréquence de déploiement doit être mesurée en heures ou en jours, et non en semaines.

Temps moyen de restauration

Le temps moyen de restauration suit le temps écoulé nécessaire pour restaurer le service après une panne de production. C'est un indicateur de la capacité d'une équipe à se remettre d'une erreur. Il doit être mesuré en minutes ou en heures, et non en jours.

Délai pour les modifications

Le délai de modification suit le temps nécessaire au code temporel pour passer de la validation à l'exécution réussie en production. Cela ne tient aucunement compte de l’ampleur, de la valeur ou de la complexité du changement. Il s’agit davantage de l’efficacité du déploiement que de l’efficacité du développement.

Modifier le taux d'échec

Le taux d'échec des modifications est un indicateur de la qualité du code déployé.

Avantages des métriques DORA

Ils sont faciles à suivre

Ils se concentrent sur les activités DevOps.

Inconvénients des métriques DORA

Ils se concentrent sur les taux de changement, quelle que soit la taille ou la valeur client.

Ils sont pour la plupart inadaptés à la planification, au dimensionnement et au suivi de projets.

Ils ne conviennent qu'au benchmarking des activités DevOps ou DevSecOps,

Benchmarks nuisibles pour le travail logiciel

Les organisations peuvent souvent capturer par erreur des indicateurs pouvant entraîner des conséquences involontaires. Ceux-ci doivent être utilisés avec beaucoup de prudence, voire évités complètement, et ne doivent pas non plus être utilisés comme base d'analyse comparative.

Lignes de codes produites par ingénieur

Cela peut amener les développeurs à écrire du code détaillé, plutôt que du code efficace ou réutilisé. Utilisez plutôt CFP produit par ingénieur

• Défauts produits par mois par ingénieur
  • Le nombre de défauts produits doit être considéré dans le contexte du résultat. Un développeur qui produit 1 défaut par mois et seulement 1 CFP est moins capable que celui qui produit 2 défauts par mois en 10 CFP. Utilisez plutôt défauts par CFP produit par ingénieur.
• Coût pour détecter un défaut
  • Plus la qualité du logiciel est élevée, plus la recherche d’un défaut est coûteuse. Un coût élevé par défaut découvert peut signifier que le logiciel a déjà une grande valeur.

Conseils d'analyse comparative interne

1. Divulguer les noms des projets sur les benchmarks comparatifs internes
2. Affichez les métriques des composants et pas seulement les valeurs globales.
3. Incluez les activités sans codage.
4. Incluez les aspects humains.
5. Utilisez des métriques de taille fonctionnelle.
6. N'utilisez pas les données pour définir des objectifs abstraits.

Résumé de Capers Jones présentation sur l'analyse comparative