Productivité pour les estimateurs de logiciels

  • Écrit par : Sarada Kaligotla
  • Date de publication : Juillet 18 2013



du logiciel, à savoir, la taille du logiciel, l'effort, le coût et le calendrier (durée) sont à l'origine de fréquentes, des discussions animées au sein de la communauté des estimateurs de logiciels. Normalement, ce sont les chefs de projets seniors et chefs de projet qui effectuent cette activité.

développement du logiciel se compose de quelques activités disparates nécessitant des connaissances spécialisées, à savoir la collecte des exigences, l'analyse et la gestion, la conception du logiciel, le codage et vérification et de validation indépendante (IV & V ), et le déploiement, le déploiement, l'installation et la mise en service. Chacune de ces activités est réalisé par une personne différente qualifié qui utilise différents outils qui varient en complexité.

productivité

productivité est défini comme le taux de sortie pour des entrées données. La productivité est exprimée en "tant d'unités de production par jour» ou «autant d'unités de production par heure.« La productivité est également défini comme le rapport de la production à l'entrée.

Dans le cadre de cet article, la productivité se référer au taux de production d'une unité de production en utilisant un ensemble d'entrées dans une unité de temps définie.

avec le logiciel Estimation de la taille

Le scénario actuel dans l'industrie du logiciel est qu'il existe plusieurs unités de mesure de taille de logiciel. Ces unités de mesure comprennent des points de fonction, utilisez points de cas (UCP), des points d'objets, points caractéristiques, les points d'Internet, des points d'essai, II analyse des points de fonction marque (FPA), lignes de de code (LOC), etc Il n'ya pas moyen accepté de convertir la taille du logiciel d'un appareil de mesure à un autre.

Un aspect étrange de ces mesures est que la taille du logiciel est ajusté (augmentation ou diminution) en fonction de facteurs tels que la complexité, par exemple. Pourtant, la taille est quelque chose qui ne change pas. Par exemple, un livre de fromage ne devient pas lourd ou plus léger si la personne pesant, il est plus ou moins expérimentés dans l'appréciation des choses, ou si l'échelle est une mécanique ou électronique, non? Comme autre exemple, la distance d'un mile reste un mile si un jeune se promène elle ou une personne âgée marche, ou si le mile est une autoroute ou d'une rue de la ville occupée.

Mais la vitesse à laquelle les résultats sont obtenus changements. Prenant les exemples ci-dessus, la personne âgée sera probablement compléter une marche d'un mile plus lentement que la jeune personne, et l'on peut se déplacer plus rapidement sur une autoroute que dans une rue de la ville occupée.

En outre, il n'existe pas d'accord sur la façon de compter LOC. Faut-il compter les états logiques ou des états physiques? Et comment peut-on traiter la documentation en ligne? Si documentation inline être compté, ou pas?

Ce sont quelques-uns des problèmes majeurs avec mesure de la taille.

avec la productivité

Le monde du développement logiciel est obsédé par donner une seule empirique, figure, tous-activités qui englobe la productivité.

ont été faits pour spécifier la productivité de 10 heures-personnes par point de fonction, mais avec un cavalier que les heures-personnes par point de fonction peuvent varier de 2 à 135 selon la taille produit, l'équipe la taille et d'autres facteurs. Qu'entend-on par "précise la productivité» consiste à attribuer un nombre qui représente l'effort en heures-personnes nécessaires pour développer une unité de la taille du logiciel pour convertir la taille du logiciel en points de fonction à l'effort de développement de logiciels en heures-personnes. Parfois, les plages sont donnés au lieu, comme quinze à trente heures par UCP. À d'autres moments, des formules empiriques sont élaborés en fonction d'un ensemble de facteurs, tels que modèle du coût constructive (COCOMO).

une des préoccupations avec ces chiffres de la productivité, c'est qu'ils forfaitaire toutes les analyses activités-exigences, la conception, l'examen, l'essai, et ainsi de suite, en une seule mesure. Pourtant, les compétences requises pour ces activités sont différentes, comme le sont les outils utilisés, les entrées et les sorties. Tous amalgamer sous le titre de "développement de logiciels" et donner un seul chiffre de la productivité au mieux ne peut résulter que d'une estimation très grossière, jamais une exacte.

Le chemin de la productivité

développement de logiciels comprend les activités suivantes:

      les activités d'avant-projet
  • , y compris une étude de faisabilité, la budgétisation financière, et les approbations pour le projet (c'est-à-approbation financière et technique, et «projet go-ahead")

  • projet
  • démarrage des activités, telles que l'identification du gestionnaire de projet, en allouant l'équipe du projet, et mettre en place l'environnement de développement, la planification du projet, la mise en place de divers protocoles, à savoir les accords de niveau de service et les formalités de déclaration d'activité, et lié au projet Training |   
  • activités
  • de logiciels d'ingénierie, à savoir, l'analyse des besoins de l'utilisateur, l'analyse des exigences du logiciel, la conception du logiciel, le codage et les tests unitaires, les différents types de tests - Intégration, fonctionnel, négatif , le système et l'acceptation et la préparation de la construction et de la documentation   

  • activités de déploiement, y compris l'installation du matériel et du logiciel système, mise en place de la base de données, l'installation du logiciel d'application, courir sur les pilotes, la formation des utilisateurs; effectuer pistes parallèles, et capotage

  • activités du projet d'assainissement, y compris documenter les bonnes et les mauvaises pratiques, d'analyser le projet (projet post-mortem), les dossiers d'archivage; libération des ressources; libérer le chef de projet, et d'initier la maintenance du logiciel

Maintenant, quand on parle de "règles d'or" de l'industrie (des procédures de bon sens accepté) de la productivité, il n'est pas clair combien de ces activités sont inclus dans le chiffre de la productivité. Fait intéressant, on ne voudrait risquer sa vie sur le chiffre de la productivité, qui est une règle de l'industrie de base qui est flottant autour.

pencher sur la nature de ces activités:

  1. Analyse des besoins - comprendre et documenter ce que l'utilisateur a besoin, veut, et s'attend donc à ce que les concepteurs de logiciels comprennent et peuvent concevoir un système en stricte conformité avec les exigences énoncées . La dépendance de facteurs externes est élevé.

  2. Software conception - en tenant compte des solutions de rechange dans les plates-formes matériel, logiciel système, et le développement; arriver au choix optimal pour chacun, et la conception d'une architecture qui permettra de répondre aux besoins exprimés et répondre aux attentes des clients. L'architecture doit être compatible avec les technologies actuelles, et la conception documenté de telle façon que les programmeurs à comprendre et à livrer un produit conforme aux spécifications d'origine de l'utilisateur. Très peu de solutions de rechange existent, et avec la conception de logiciels étant une activité clé et stratégique, des erreurs ici avoir des conséquences graves.

  3. Coding - le développement de code logiciel qui est conforme à la conception et qui est aussi sans défaillance possible (il est si facile de quitter involontairement "bugs" à l'intérieur).

  4. Revue de code -. marche à travers le code écrit par un autre programmeur, déchiffrer ses fonctionnalités, et d'essayer de prédire les éventuelles erreurs que le client pourrait rencontrer en utilisant le logiciel

  5. Testing - en essayant de dénicher tous les défauts qui peuvent être laissées dans le logiciel. Cependant, il est un fait reconnu dans l'industrie que trouver 100 pour cent des défauts est impossible. En outre, l'essai 100 pour cent du logiciel est une entreprise impossible.

Maintenant, avec une telle variance dans la nature de ces activités, il est évident que la productivité de chacun d'entre eux n'est pas uniforme (c'est-à-dire, pas la même figure). Le rythme de travail est différent pour chacune de ces activités.

Ces activités ne dépendent pas de la quantité de code logiciel produit, mais plutôt sur d'autres facteurs, tels que

      exigences de
  1. , qui dépendent de l'efficacité et de la clarté de leur source (des utilisateurs ou des documents);   
  2. conception
  3. , qui dépend de la complexité du traitement, des alternatives existent, et les contraintes dans lesquelles la fonctionnalité est à réaliser;   
  4. Code
  5. examen, qui dépend du style de codage;   
  6. test
  7. , qui dépend de la façon dont le code est écrit (les erreurs les plus qui sont laissés, plus le temps qu'il faut pour tester et re-tester) et
  8. l'codant lui-même, qui dépend de la qualité de la conception.

Par conséquent, nous avons besoin de chiffres de la productivité distincts pour chacune de ces activités.

Dressant un parallèle de la fabrication des trous industrie l'emporte-pièce dans une feuille voici les activités qui doivent être menées: 1) réglage de la machine; 2) outil de configuration; 3) le chargement du travail; 4) de percer le trou; 5) ébavurage du trou; 6) nettoyer et 7) délivrant la feuille pour la prochaine opération

.

Si plusieurs trous sont percés, "par trou" temps revient, que les activités mise en place des activités ponctuelles.

Par conséquent, si nous regardons une unité de codage, par exemple, les activités à réaliser pourrait être 1) recevoir les instructions, 2) étudier le document de conception; 3) le code unitaires, 4) tester et déboguer l'unité de fonctionnalité; 5) tester et déboguer l'unité pour un usage involontaire; 6) supprimer le code de la corbeille de l'unité; 7) régression-test de l'unité;. et 8) libérer l'unité pour la prochaine étape

même, on peut arriver à micro-activités pour chaque phase de développement de logiciels.

: empirique ou étude basée

Chacune de ces activités a un taux différent de réalisation. Fois standard pour chacune de ces activités doivent être établis. Une fois cela fait, travailler les techniques d'étude, tels que la synthèse ou l'estimation analytique, devrait être utilisée pour arriver à l'heure ensemble pour terminer le travail.

class="articleText">

Où allons-nous obtenir des données empiriques? Une façon est à travers des études de temps en utilisant des techniques de génie industriel. Une autre façon, ce qui est plus facile et plus fiable, c'est à partir de données historiques des feuilles de temps.

La plupart des logiciels de feuilles de temps disponible et utilisé dans l'industrie est orientée vers la paie et de la facturation. Il ne tient pas compte des données au niveau micro-économique afin qu'elle puisse être utilisée pour arriver à des données sur la productivité. La plupart des feuilles de temps saisir les données à deux ou trois niveaux en plus de la date et de l'heure. Un projet est toujours au niveau du premier niveau, et les deuxième et troisième niveaux peut être occupée par le module et le composant, le composant et l'activité, ou à une combinaison similaire. En plus de la date et de l'heure travaillée de chaque employé, la feuille de temps doit capturer des données à cinq niveaux, à savoir, projet, modules, composants, la phase de développement, et la tâche accomplie. Ainsi, les données seraient disponibles pour établir des données de productivité empirique d'une manière réaliste.

La présente mise au point pour toutes les activités de développement de logiciels est le macro-productivité. Cela doit changer, et nous devons nous concentrer à partir de macro à la micro-productivité pour toutes les activités. La manière de réaliser ce changement est de modifier nos feuilles de temps et la profondeur des données qu'ils recueillent.

avantages d'étudier la productivité au niveau micro-économique sont les suivants:

  • une meilleure prévisibilité de développement de logiciels   
  • estimations de meilleure qualité pour l'assistance des prix lors de l'acquisition du projet et les étapes de sanction
  •   la fixation d'objectifs
  • plus précis tandis que la répartition du travail, ce qui conduit à un meilleur moral chez les développeurs de logiciels
  • estimation plus précise des coûts

Conclusion

Il est important de comprendre la différence entre la productivité et la capacité termes. La productivité est le taux de réussite pour une micro-activité de l'activité humaine, la capacité est le taux de réussite pour une installation (usine, organisation, etc), et de multiples activités sont inclus dans le chiffre désignant la capacité. Aux fins de l'estimation du logiciel, l'accent doit passer de la macro-productivité (capacité) à la productivité (pour micro-activité). Empiriques de collecte de données est préférable pour arriver à des chiffres de productivité pour les diverses activités de développement de logiciels, les techniques d'étude de temps et mouvements ne peuvent pas donner des résultats satisfaisants où il existe une certaine composante de la créativité (comme il le fait dans le développement de logiciels). Une façon de recueillir les données empiriques est d'améliorer la feuille de temps. C'est la voie à suivre pour calculer les chiffres de la productivité au niveau microéconomique.

propos des auteurs

Murali Chemuturi est un homme de génie industriel à l'Institut indien de génie industriel. Sa carrière a duré plus de trente ans d'expérience avec les organisations professionnelles, y compris ECIL, TCS, Metamor et Satyam. Il a d'abord travaillé dans le secteur manufacturier, puis dans l'informatique. Il dirige actuellement Chemuturi Consultants, en se concentrant sur les produits logiciels pour l'industrie du développement logiciel. Il a mené un certain nombre de programmes de formation en entreprise pour la gestion de projet logiciel et l'estimation des logiciels. Il peut être contacté à murali@chemuturi.com.

Sarada Kaligotla a terminé sa maîtrise en applications informatiques, et est un professionnel certifié en gestion de projet (PMP) du Project Management Institute (PMI), et un analyste de la qualité des logiciels certifiés (CSQA) de la Quality Assurance Institute (QAI). Elle travaille actuellement pour Blue Cross Blue Shield du Massachusetts. Kaligotla a six ans d'expérience dans l'industrie du logiciel, ainsi que le développement et l'expérience de gestion de projet. Elle peut être contactée à sarada14@yahoo.com

 
comments powered by Disqus