mesure de la productivité

Dans d'autres secteurs que l'industrie du logiciel, mesure de la productivité est une activité normale qui entraîne le succès d'une entreprise. Voyons voir par exemple une entreprise de peinture d'un homme. Pour un peintre, il serait logique de mesurer sa productivité dans heures d'effort par mètre carré. Probablement qu'il veut différencier la mesure dans certaines catégories,comme des outils utilisés (par exemple. rouleau / brosse / pulvérisation / etc.) et peindre caractéristiques de l'objet (par exemple. mur / escaliers / porte / etc.). Quand le peintre construit une base de données avec les chiffres de la productivité, il peut facilement citer de nouveaux travaux de peinture, simplement en mesurant la surface de peinture en mètres carrés, en multipliant le taux de productivité adéquate et multiplier le résultat avec le taux horaire, il demande. S'il y a un (international) base de données disponible avec les taux de productivité des travaux de peinture réalisée par d'autres sociétés dans l'industrie, le peintre comprend comment il effectue en moyenne contre l'industrie et au cas où il n'est pas mieux en classe déjà, il comprend que pour gagner de nouveaux travaux de peinture qu'il doit continuer à améliorer sa productivité (en abaissant le taux horaire est généralement pas une très bonne idée).

Il peut faire tout cela, mais seulement quand:

  • Il utilise un unité de mesure standard, par exemple. mètre carré. Seule l'utilisation de normes, les taux de productivité peuvent être comparés (benchmarkée) et utilisé pour Estimation;
  • Il utilise un moyen standard pour enregistrer les heures d'effort. Par exemple, est la pause déjeuner inclus ou exclus, est le temps de parler au client de comprendre ses besoins inclus / exclus?
  • Il utilise mCatégories eaningful que la productivité Différencier. Pour un peintre, il importe peu trop si l'objet de la peinture (disons un mur) est dans une villa ou dans la maison d'un pêcheur. Le type de maison peut ne pas être une catégorie significative. pourtant, l'outil qu'il utilise est probablement un facteur de productivité principale.

Maintenant, nous allons jeter un oeil à l'industrie du logiciel.

L'industrie du logiciel et de mesure de la productivité

Malheureusement, IT (et logiciels) l'industrie est encore assez immature quand il est à l'utilisation de normes et en matière de productivité (performance) la mesure, analyse comparative et l'amélioration continue. L'industrie est parti avec qui depuis longtemps, parce que:

  • Il est difficile de mesurer production (logiciel n'est pas une chose physique, ne peut pas être touché et mesurée avec des instruments de mesure conventionnels).
  • Projets de logiciels sont beaucoup plus comme un R&projet D que la fabrication d'un produit. R&D est incroyablement difficile à mesurer. Il est relativement facile de mesurer les entrées, mais les résultats sont difficiles à mesurer et imprévisible par nature.

Maintenant, lentement l'industrie devient de plus en plus transparent et les organisations de clients potentiels demander aux fournisseurs de plus en plus à quantifier leur performance en fonction des données historiques. Par ici, il devient possible de sélectionner le meilleur fournisseur pour l'emploi. S'il vous plaît noter que le meilleur choix est généralement pas le moins cher choix (ce qui entraîne souvent des défaillances du projet…ou même les catastrophes).

Normes

Il peut sembler facile à mettre en œuvre un processus de mesure de la productivité dans une organisation, la réalité montre qu'il est plus difficile que l'on peut penser. En principe, tout comme le peintre, il suffit de Entrées de mesure (généralement heures d'effort) et sorties (Unités de mesure, UdM) par projet logiciel, tandis que en utilisant des catégories significatives pour différencier les projets, comme la technologie (Java / .Net / Oracle / etc.), Type de projet (nouveau développement / amélioration) et / ou la mise en œuvre (Paquet mise en œuvre / modification / logiciel fait sur mesure).

Pour être en mesure de mettre en place des mesures de productivité significatifs et comparables, il est essentiel que (international) les normes sont utilisées. Un certain nombre de choix doivent être faits:

Entrées de mesure

Certaines décisions qui doivent être:

  • heure de l'effort dans / hors portée de la mesure, par exemple
    • conception technique, codage, Test de l'unité, test de systèmes, d'autres tests fournisseur, les frais généraux de portée;
    • conception fonctionnelle, soutien test d'acceptation, les activités de mise en œuvre hors de portée.
  • Les heures supplémentaires avant / arrière étendue de mesure;
  • heures de voyage, heures de réunion, heures aériennes dans / hors champ;
  • Dans le cas des emballages, Portails / CMS ou d'autres logiciels configurables, il peut être nécessaire d'avoir des activités d'enregistrement des efforts distincts pour la personnalisation, le réglage des paramètres et des logiciels sur mesure ne fait pas partie du paquet.

Pour être en mesure d'analyser la productivité d'un fournisseur, département ou équipe, le système d'enregistrement des efforts devraient être mis en œuvre de manière standard. Si le choix est fait que les heures de conception fonctionnelle sont hors de portée, tous les projets doivent inscrire leurs efforts de conception fonctionnelle séparément des autres heures d'effort. Il est fortement recommandé d'élaborer une norme « Work Breakdown Structure (WBS)’ par type de projet et mettre en œuvre ce WBS dans le système d'enregistrement de l'effort. Tout le monde qui enregistre les heures d'effort doit être conscient de l'importance de la réservation correctement leurs efforts dans le système.

Sorties de mesure, méthodes qui devraient être évitées

sorties de mesure est un peu plus difficile que la mesure des entrées, en raison de la nature intangible des logiciels. De nombreuses organisations mesurent les lignes de source livrées de code (slocs) du logiciel après achèvement et livré l'utilisation des mesures de productivité comme les heures d'effort par 1000 slocs. Cela semble être une bonne façon d'aller, mais en fait il y a beaucoup de raisons pour lesquelles ce n'est pas une pratique recommandée:

  • Il n'y a pas (ISO ou autre) Norme pour les lignes du code source. Le résultat est que les différents outils de comptage automatique de code produisent (très) résultats différents pour le même code.
  • On ne sait pas si le code est plus « bon’ ou mauvais'. Les lignes de source de code ne sont pas de valeur pour l'organisation du client. La fonctionnalité est de la valeur. Les clients ne disent jamais:”S'il te plait donne moi 100000 des lignes de source de code”. Non, il est une fonctionnalité en termes de fonctionnalités dont ils ont besoin. Plus de fonctionnalités est meilleure et les coûts plus, plus slocs est peut-être pas mieux.
  • Différents langages de programmation (et les mélanges de ceux-ci) entraîner des lignes de source très différents des résultats de code.

gourou métrique de logiciel américain »’ Capers Jones a écrit dans un logiciel » papier Origines et défauts des méthodes d'enlèvement (2013) que les mesures de SLOC sont si imprécis, que l'utilisation slocs dans la mesure du logiciel est en fait « Faute professionnelle ».

D'autres mesures de taille qui sont souvent utilisés dans l'industrie, mais sont également non recommandé à utiliser dans la mesure de la productivité:

  • points d'histoire (SP) dans les projets agiles: Une mesure très subjective qui n'a de valeur que dans l'équipe. Comparaison avec d'autres équipes, ministères et organismes n'est pas possible. S'il vous plaît noter que SP sont utiles pour les sprints du plan et de suivre la vitesse pour une équipe, mais pour la mesure de la productivité SP sont proches inutiles.
  • Points uSECASE (UCP): Applicable uniquement lorsque la documentation se compose de usecases. UCP est aussi une méthode très subjective, en particulier en ce qui concerne l'établissement du facteur de complexité technique et le facteur environnemental. Aussi, il n'y a aucun moyen standard d'écrire usecases, voir par exemple cinq niveaux possibles de granularité comme décrit ici.
  • Points de complexité: Subjective et non méthode normalisée pour mesurer la complexité d'une application.
  • IBRA Points: Non méthode standardisée pour mesurer les règles métier dans une application. Appliqué selon le manuel, le résultat est égal à zéro pour toutes les applications.
  • Points de fonction rapide (LPIF) (par Gartner): Procédé de mesure déployée par Gartner qui ne peut être comparée aux méthodes d'analyse des points de fonction normalisés ISO. LPIF est perçue comme une méthode commerciale qui manque une base théorique et est en partie subjective. La méthode n'a pas prouvé être plus rapide que la méthode estimée Nesma et n'a pas prouvé pour être plus précis. Malheureusement, il est souvent poussé au niveau de la haute direction sans le soutien des spécialistes qui ont à travailler avec elle.

sortie de mesure – méthodes fortement recommandées

C'est un une pratique hautement recommandée d'utiliser un norme ISO / CEI pour la mesure de la taille fonctionnelle en mesure de la productivité des projets logiciels. Il existe cinq méthodes de mesure de la taille fonctionnelle qui sont conformes à la norme ISO / CEI:

  • points de fonction Nesma (ISO / CEI 24570);
  • IFPUG points de fonction (ISO / CEI 20926);
  • COSMIQUE points de fonction (ISO / CEI 19761);
  • Mark II points de fonction (ISO / CEI 20968);
  • FISMA points de fonction (ISO / CEI 29881).

Avantages de l'utilisation de ces méthodes de mesure de la taille fonctionnelle pour la mesure de la productivité sont:

  • Objectif, répétables, vérifiable, manière défendable pour déterminer la taille du logiciel;
  • Une relation claire entre la taille fonctionnelle et les efforts nécessaires pour réaliser les application.This a été étudié et vérifié plusieurs fois;
  • La mesure est clair pour les organisations clientes et les organisations de fournisseurs. Plus de fonctionnalités signifie plus de valeur, plus d'effort nécessaire et un prix plus élevé;
  • la taille fonctionnelle est indépendante de la solution technique et / ou les exigences non fonctionnelles. Une application de 500 points de fonction NESMA réalisés en Java est tout aussi grand qu'un site Web Wordpress de 500 FP. Ceci permet la comparaison et l'analyse comparative sur les domaines techniques et l'utilisation des données du projet historique (lorsqu'ils sont correctement classés) dans l'estimation de nouveaux projets de logiciels.

Catégories utiles pour la collecte de données

Pour pouvoir comparer et évaluer votre productivité, il est important d'utiliser les catégories standard pour les données de vos projets Collect. Nesma recommande fortement d'utiliser les définitions et les catégories le Groupe des normes Benchmarking Software International (ISBSG) utilise dans leurs activités de collecte de données.

Le logiciel International Benchmarking Standards Group (ISBSG) est un « sans but lucratif’ organisation qui collecte des données de l'industrie des logiciels et qui pousse, entretient et exploite deux référentiels: « Les nouveaux développements et améliorations’ et « Maintenance & Soutien'. ISBSG ne peut le faire lorsque les données sont collectées de manière standard. La « collecte de données Questionnaires’ peut être téléchargé à partir du Site ISBSG et montrent déjà beaucoup de définitions et catégories. De plus, les glossaires qui sont fournis avec les dépôts sont utiles.

La mise en œuvre mesure de la productivité du logiciel

Donc, tout comme le peintre de l'exemple ci-dessus, il est possible de mesurer la productivité des projets logiciels. Voir cette page pour quelques exemples.

Pour mener à bien la mesure de la productivité du logiciel, il est fortement recommandé d'utiliser le document « base de mesures’ qui figure dans la liste des publications.