est un paramètre corrige local local pour l'estimation du projet?
Il y a tellement de scénarios où la complexité prend beaucoup plus de temps pour une seule ligne de code, autre que loc, ce qui pourrait être le paramètre suggéré pour l'estimation du projet?
Comme les peuples parlent de point de programme fonctionnel signifie-t-il pour utiliser les informations liées au cas?
J'essaie de trouver une base solide pour une estimation complète du développement logiciel qui peut consister une analyse, une conception, une préparation de test et un codage, veuillez suggérer?
6 Réponses :
Seulement si vous l'utilisez dans l'inverse.
- Modifier
mais non. Ce n'est pas le cas. C'est une mesure surtout inutile et généralement nuisible. Comme vous le souhaitez, moins de code est presque toujours mieux.
Autres choses à vérifier? Eh bien, qu'essayez-vous de mesurer? Quel résultat voulez-vous voir d'un changement de choses que vous vérifiez? Quelles décisions allez-vous prendre sur la base de ces changements?
Steve McConnell en développement rapide (Microsoft Press, 1996):
car une programmation différente Les langues produisent des franges si différentes Pour un nombre donné de lignes de code, Une grande partie de l'industrie du logiciel est se déplacer vers une mesure appelée "points de fonction" pour estimer le programme tailles. Un point de fonction est synthétique mesure de la taille du programme basée sur la taille du programme sur une somme pondérée du nombre de Entrées, sorties, demandes de renseignements et fichiers. Les points de fonction sont utiles car Ils vous permettent de penser au programme taille dans une voie de langageIndependes.
Google "point de fonction" pour plus d'informations.
location est une mesure proxy pour mesurer la taille de problème .
L'estimation locale peut être utilisée et le nombre local est relativement peu coûteux de mesurer à partir de projets historiques. Mais LOC peut être problématique s'il est utilisé pour autre chose qu'un proxy pour la taille du problème, comme indiqué déjà par d'autres réponses.
La taille du problème est plutôt constante compte tenu des exigences. D'une estimation de la taille, vous pouvez aller à l'effort, au calendrier et aux estimations des coûts. Cela dépend de vos pilotes de planification tels que le coût ou l'horaire. Du des données historiques, vous pouvez trouver la corrélation Comment la taille du problème se traduit par les efforts et la manière dont les autres conducteurs de planification influencent davantage sur le résultat. Vous devez donc mesurer la mesure de la taille et l'effort contre d'autres paramètres et continuer à régler votre processus d'estimation. Il existe des mesures locales à l'effort disponibles dans la littérature, mais elles ne sont pas très précises dans votre domaine, en utilisant la technologie que vous utilisez et l'équipe que vous avez.
D'autres proxies pour la taille des problèmes sont des points de fonctionnement et des points d'histoire. Mon expérience sur les points de fonction est qu'ils valent rarement l'effort. D'autre part, des points d'histoire dans les méthodes agiles fonctionnent très bien depuis leur abstraite (évitant ainsi beaucoup de problèmes avec LOC) et mesurés sur une base sprint à la sprint, avec des commentaires instantanés dans des sprints suivants.
Voir que les développeurs sont susceptibles de * passer la majeure partie de leur temps à essayer de tester les modifications, les lignes de code ne sont jamais un bon indicateur de taille d'un problème.
Supposons que vous ayez une application importante existante - changer une ligne de code unique peut sembler triviale, mais la planification et l'exécution des tests pouvaient prendre des semaines.
De même, l'ajout d'une quantité relativement importante de code dans un seul module à portée limitée qui est facilement testable ne peut être que quelques jours.
* Ils devraient faire, au moins. S'ils passent plus de temps à écrire du code que de le tester, il est probablement plein de bugs. Et je veux dire avant d'atteindre votre équipe de QA dédiée.
Non, ce n'est pas le cas. La raison est simple: si vous produisez une nouvelle ligne de code pendant votre développement, êtes-vous un pas plus proche d'une solution? Si vous avez estimé 1000 lignes de code pour compléter une tâche, êtes-vous terminé de 0,1% avec cette tâche?
Les lignes de code peuvent être utilisées comme une métrique mais uniquement dans le sens négatif: pour un plus grand nombre de lignes de code, il est raisonnable de supposer que vous avez un plus grand nombre de bugs. Sur la base de données historiques, il existe généralement une corrélation linéaire entre les lignes de code et le nombre de bugs.
Voici quelques facteurs utiles et mesurables qui valent la peine d'être envisagés:
En bref, les lignes de code sont très presque la pire métrique possible que vous puissiez utiliser.
Le seul moyen d'obtenir une estimation raisonnable sur la durée du projet consiste à mettre en œuvre complètement et à fournir un sous-ensemble des exigences finales. Ensuite, vous pouvez estimer les exigences restantes en comparant leur complexité contre les travaux terminés.