Comment déterminer la taille d'un projet (lignes de code, points de fonction, autres)
Comment évaluez-vous la taille du projet?
Partie A: Avant de commencer un projet.
Partie B: Pour un projet complet.
Je suis intéressé par la comparaison de projets indépendants. Voici quelques options:
1) Lignes de code.
- Je sais que ce n'est pas une bonne mesure de la productivité, mais est-ce une mesure raisonnable de la taille du projet?
- Si je voulais estimer combien de temps il faudrait pour recréer un projet serait-ce un moyen raisonnable de le faire? Combien de lignes de code dois-je estimer un jour?
2) Les Points De Fonction.
- Fonctions de points sont définis comme le nombre de:
- entrées
- sorties
- demandes de renseignements
- fichiers internes
- interfaces externes
- Quelqu'un a un point de vue à savoir si c'est une bonne mesure?
- Est-il un moyen de **de faire ça?
Quelqu'un aurait-il une autre solution? Les heures prises semble que cela pourrait être une mesure utile, mais pas uniquement. Si je vous demande ce qu'est un "plus" et de vous donner deux programmes comment voulez-vous l'approche de la question?
J'ai vu plusieurs discussions de ce sur stackover débit, mais la plupart discuter de la façon de mesurer la productivité du programmeur. Je suis plus intéressé à la taille du projet.
Puis-je vous demander pourquoi vous voulez savoir ce que l'on cherche à atteindre? Qui peut avoir un impact sur la mesure la plus appropriée. Essentiellement, qu'entendez-vous par taille?
OriginalL'auteur sixtyfootersdude | 2010-05-31
Vous devez vous connecter pour publier un commentaire.
Nous utilisons "l'homme-jour" à estimer le coût d'un projet.
Dans combien de jour un seul homme moyen sera de terminer le projet. (eh bien, combien d'années parfois)
Lignes de code ne sont pas le meilleur mais pas le pire de l'unité, mais exclure les "bibliothèques".
Une étude a estimé qu'un développeur peut écrire une dizaine de lignes/jour, ce qui reste dans la finale programm. (mais il fera aussi de la conception, de la documentation, de la gestion de projet, etc...)
Par exemple, vérifier Ohloh projet une analyse de certains projets open-source, ils ont estimé le coût à la COCOMO algorithme (calculatrice en ligne).
La base est de lignes de code.
Pendant les Cours, de retour à l'école, désolé je n'ai pas de sources en ligne. Mais je suppose que c'est sous-estimé, puisque le sujet était d'insister sur le coût de bug de détection de phase dans les grandes projet de. Et je le répète : c'est la dernière contribution par journée de travail sur un projet d'ensemble. Pas la production/jour d'un programmeur. Je serai intéressé dans d'autres réponses.
OriginalL'auteur Syprien
Partie D'Un
Il est difficile de mesurer un projet avant de commencer. Si vous avez jamais été sur toute raisonnablement grand projet de logiciel (dont il semble que vous ayez été), les exigences en fait de changer au fil du temps. Mais, je pense que les points d'histoire sont une bonne façon de mesurer la taille des logiciels si vous travaillez dans un environnement agile. Au début du projet, vous n'aurez pas tous les détails, mais vous devriez avoir assez pour donner une estimation. Le cône d'incertitude http://www.construx.com/Page.aspx?hid=1648 donne une belle visualisation de la façon dont précis/précise, vous êtes susceptible de l'être.
La Partie B
Vous pouvez utiliser des points d'histoire ici. Après que le projet est terminé, vous devez savoir combien de points vous avez terminé. Vous serez également en mesure de mesurer votre équipe de la vitesse (points d'histoire, divisée par une certaine période).
L'une des clés est ici que vos équipes sont à l'aide d'une mesure similaire de points d'histoire, ainsi, la tâche de l'équipe qui prend 2 points d'histoire est l'équivalent de votre équipe de 2 point d'histoire.
OriginalL'auteur Jeff Storey
Partie A:
À mon humble avis, les méthodes agiles offrent le meilleur moyen d'évaluer la portée du projet a-priori. Vous avez une équipe avec une vitesse, une première coupe à une libération de l'arriéré et ont la taille d'histoires de la même façon pour les projets dont l'équipe a créé leur vitesse. Il y a une bonne série de diapositives à http://www.rallydev.com/learn_agile/agile_planning/release_planning/ si vous êtes intéressé.
Agilists ferai remarquer que vous êtes effectivement le choix pour varier le champ d'application rapport de la date/de la qualité. Donc, techniquement, vous n'êtes pas d'estimer la taille du projet. Plutôt que vous la priorité de votre carnet de commandes à rentrer dans une période de temps fixe. Encore, une équipe expérimentée avec établi vitesse peut vous donner une idée raisonnable de ce qui sera livré au moment.
Partie B:
Je pense que la clé de partie de votre question est "non reliés". OMI ces mesures ne détiennent que si vous êtes à la comparaison des projets similaires en ce qui concerne l'équipe, l'expertise, l'environnement de développement, domaine d'application, etc. Le plus "indépendants", les projets, plus il est difficile de comparer la taille du projet. Le KLOC et la Fonction de Point de métriques semblent être les plus largement utilisés.
Il ya une société appelée QVM Associés (http://www.qsma.com/tools.html) qui a une grande base de données de comparaison des projets. Vous pouvez consulter leur site pour les ressources.
OriginalL'auteur Rob
Puis-je recommander un excellent livre sur le sujet - Le Développement Rapide De par Steve McConnell. C'est par le même gars qui a écrit le Code Complet et est à mon humble avis, de loin, beaucoup mieux et le plus important du livre. Il vous dira tout vous devez savoir sur l'estimation du projet et de la mesure.
OriginalL'auteur
Comment OP mesurer la taille du projet ? Je veux dire, ce que les unités de mesure de l'OP utiliser ? Dans votre réponse, veillez à suggérer des mesures de la taille du projet, plutôt que de (ordinateur) la taille du programme.
En réponse à la partie A, je voudrais utiliser de temps et d'efforts. Le temps mesuré en jours (ou d'heures si c'est un assez petit projet), de l'effort mesuré en nombre de personnes. Cela donne coût = x fois que la personne coût. Dans la planification du projet, il est également indispensable que les estimations de mesure (de quoi que ce soit) sont accompagnés par des estimations de la variation de ces estimations, par exemple, de 2 millions de dollars (+/- 0,2 M$).
Je pourrais utiliser les mesures de l'ordinateur la taille du programme tels que la LDC ou la fonction de points de faire des estimations pour la programmation des parties d'un projet. Mais je ne voudrais pas utiliser de telles estimations et d'un multiplicateur (dire) pour l'estimation du coût du programme et de la durée. Je veux dire, je ne voudrais pas utiliser une estimation de 100 jours de programmation de plus d'un facteur de 2,5 pour obtenir un projet de taille de 250 jours.
Bien sûr, au début, quand tout ce que vous avez est une des deux lignes de description du projet, puis tout ce que vous obtiendrez est une vague estimation avec une grande erreur de limites. Comme vous affiner le plan, et d'identifier des sous-tâches, vous pouvez estimer avec plus de précision.
Une fois que le projet est terminé et je souhaite que mes statistiques dans la même forme que l'original de mes estimations, à des fins de comparabilité, de temps et d'effort et de coût. Je ne suis pas sûr que je serais jamais utiliser la LDC comme une mesure de la productivité, même rétrospectivement, je serais beaucoup plus enclins à utiliser une certaine mesure de la fonctionnalité offerte, bien que le niveau des approches telles que la fonction d'analyse des points ne fonctionnent pas très bien dans le domaine, je travaille en ce moment, scientifiques et techniques complexes codes.
EDIT: ma suggestion de temps, d'efforts et de coûts que les mesures appropriées est, en partie, basée sur mes expériences en tant que chef de projet traitant avec les autres parties prenantes, telles que les clients, les gestionnaires, etc. La gestion de projet est une activité de l'entreprise, et de parler de la LDC et de la fonction des points de, disons, le chef comptable ou de l'équipe de vente et marketing, n'est pas la bonne façon de faire.
OriginalL'auteur High Performance Mark
Je ne suis pas sûr si cela se qualifier à titre de réponse, mais ma réputation est trop faible pour commentaire.
Votre question est très, très large. Il y a beaucoup de livres qui essaient de répondre à vos préoccupations avec diverses chance.
Essayant de reprendre un champ entier, en quelques lignes est (au moins) trompeuse.
Je suggère de commencer ici: http://www.itmpi.org/ qui est un bon site, plein de liens et appropriée bibliografy.
OriginalL'auteur Dr. belisarius
Lignes de code est une mesure dangereuse à utiliser exclusivement. Considérons 2 développeurs celui qui écrit quelques fonctionnalités en 3 lignes et une autre qui permet d'obtenir le même dans 50 lignes. Qui est le plus productif? J'ai vu exactement ce sur un système à grande échelle. C'est pourquoi j'ai tendance à orienter clairement de LOC.
Je suis un grand fan de la fonctionnelle de dimensionnement à l'aide de points de fonction. Ils prennent un peu d'apprentissage, mais une fois que vous avez appris les règles pour ce qui compter et comment, ils apportent la certitude où il en est autrement de la subjectivité. La publication de mesures, basées sur les Points de Fonction, peut révéler une foule de aperçu de vos logiciels et de projets, que vous ne permettrait pas d'obtenir à partir de LOC.
Tellement convaincus de leur utilité, j'ai écrit une application pour tous à utiliser qui rend plus facile et plus rapide de compter les Points de Fonction: projectsizer.com
Comptage de 300 FP dans une journée est tout à fait réalisable. NOUS coût moyen par FP pour un MI du système est d'environ 1500 USD alors qu'il vaut bien un jour à compter 300 d'entre eux.
OriginalL'auteur Colin Hammond