Estimation des coûts des logiciels [clôturé]


10

J'ai vu sur mon lieu de travail (une université) la plupart des étudiants faire l'estimation du coût du logiciel de leur travail de diplôme final en utilisant COCOMO . Je suppose que cette façon d'estimer les coûts est un peu ancienne (dates COCOMO de 1981), d'où ma question:

How do you estimate costs in your software?

J'ai vu des choses comme:

Coût = (HoursOfWork + EstimatedIddle) * Taux horaire

Ce n'est pas ce que je veux, je cherche un modèle de coût correctement (scientifiquement) défini

EDIT J'ai trouvé quelques questions connexes sur SO:


30
"Comment estimez-vous les coûts de votre logiciel?" Mal, comme tout le monde.
Rein Henrichs

1
Il s'agit en fait de deux questions. Je vous suggère de le réécrire comme une question principale qui ne dépend pas d'un logiciel ésotérique. Je doute que vous obtiendrez de nombreuses réponses si l'exigence est la connaissance de Cocomo
Eran Galperin

@Eran, je vais suivre votre conseil et réécrire la question alors ...
David Conde

4
Steve McConnell est considéré comme un leader d'opinion dans ce domaine par de nombreuses personnes en informatique. Vous devriez jeter un œil à son livre. stevemcconnell.com/est.htm
Jeff

5
Je vote pour fermer cette question comme hors sujet car il ne s'agit pas d'un problème de programmation conceptuelle dans le cadre défini dans le centre d'aide .
durron597

Réponses:


16

Si vous êtes coincé en mode cascade, la seule méthode assez précise que j'ai utilisée est:

  1. Créer une structure de répartition du travail
  2. Assurez-vous qu'il est suffisamment détaillé pour pouvoir relier l'ampleur de chaque tâche à quelque chose que vous (ou quelqu'un à qui vous pouvez parler) a déjà fait.
  3. Pour chaque tâche, déterminez les meilleurs cas, les cas probables et les pires cas en fonction de l'expérience. Dans le meilleur des cas, si tout s'est parfaitement déroulé, dans le pire des cas, si vous deviez le refaire (peut-être deux fois) et qu'il y a probablement quelque part là-dedans.
  4. Utilisez une formule de pondération comme (1 * meilleur + 4 * probable + 1 * pire) / 6 pour arriver à une estimation pour chaque tâche qui tient compte de la plage.
  5. J'ai également vu des variantes où vous pouvez ajouter un composant "risque" à chaque tâche. Les trois niveaux de risque sont 0, 1 et 2. Un risque de 0 signifie que vous l'avez déjà fait (ou quelque chose de très proche), 1 signifie que vous ne l'avez pas fait auparavant, mais c'est fait régulièrement dans votre industrie, 2 signifie que cela n'a probablement jamais été fait auparavant dans l'industrie. Vous prenez le nombre de risque et le multipliez par une approximation de l '«écart-type» de votre estimation. Ajoutez cela à votre estimation pondérée. Donc, un risque de 0 ne le déplace pas, mais un risque de 2 le déplace assez près de votre pire cas.
  6. Additionnez toutes les tâches.
  7. Ajoutez une contingence (quelques%) pour les "inconnus inconnus".

Vous vous retrouverez avec un nombre très précis. Je ne dis pas que c'est exact, mais ce sera précis.

La précision dépend entièrement de la possibilité de trouver un numéro pour chaque tâche en fonction de l'expérience passée, ou de trouver quelqu'un qui l'a déjà fait. Plus vous avez d'expérience, meilleures sont vos estimations.

Lorsque vous exécutez le projet, suivez votre temps par rapport à chaque tâche et notez celles que vous avez manquées, afin de pouvoir comparer. Cela vous rendra meilleur au fil du temps.


Merci @Scott, je recommanderai quelque chose comme votre idée ..
David Conde

1
Faites votre estimation de cette façon, puis estimez indépendamment une deuxième façon (et / ou une deuxième personne fait les estimations). Comparez les résultats. Tout ce qui est éloigné ou sensiblement différent du «sentiment d'intestin» doit être examiné. D'après mon expérience (25 ans et plus), le «sentiment d'intestin» est souvent plus précis que n'importe quelle formule de fantaisie, ignorez-le à vos risques et périls.
mattnz

@mattnz - l'intuition a la même mise en garde: cela ne fonctionne que si vous avez beaucoup d'expérience. Chaque client a le «sentiment profond» que cela va coûter beaucoup moins cher qu'il ne le fait, car ils ne comprennent pas la quantité de travail nécessaire dans les cas d'angle.
Scott Whitlock

3
Un autre conseil: «Je ne négocie pas d'estimations. <Longue pause>» est une expression très utile lors des réunions avec les patrons / clients. Après tout, votre mécanicien automobile ou votre chirurgien le fait-il? Il peut négocier le prix, il peut négocier quel travail est fait ou comment il est fait, mais je n'ai jamais vu un homme de métier pour un professionnel dans un domaine autre que le logiciel négocier la durée d'un travail.
mattnz

@mattnz - J'ai négocié avec un mécanicien automobile la semaine dernière sur le temps qu'il faudrait pour réparer la portière de ma voiture en fonction de la façon dont cela a été fait.
sixtyfootersdude

3

L'estimation logicielle est extrêmement difficile. Une approche que j'ai utilisée consiste à décomposer les exigences aussi finement que possible et à estimer chaque pièce séparément. Ajoutez ensuite un «facteur de fudge» qui peut être soit un multiplicateur (le doubler) soit un montant fixe (x heures pour un travail imprévu). Si vous n'avez pas de bonnes exigences, l'estimation est impossible à des fins pratiques.


1
Les estimations les plus réussies que j'ai vues (sans compter celles utilisant des méthodes sophistiquées) sont celles qui ont grossièrement doublé l'estimation originale.
Bernard Dy

1
Ouaip, double. L'un des gestionnaires les plus performants sur le plan politique pour lequel j'ai travaillé a pris les estimations des développeurs, les a triplées , puis a négocié avec les utilisateurs pour doubler. Le plus souvent, les dates de livraison négociées ont été atteintes.
DaveE

0

L'industrie a beaucoup appris au cours des 30 années qui ont suivi 81. Estimer comme ça n'a jamais fonctionné. L'engouement agile ayant essentiellement réécrit le paysage, nous utilisons des «points d'histoire» représentant une «difficulté comparative» floue. Nous gagnons ensuite en "vitesse" pour que les foutus puissent faire leurs estimations de $$ avec une certaine quantité de données empiriques.


0

J'ai appris certaines approches "rigoureuses" telles que les estimations de points de fonction et certaines variantes de celles-ci qui ont été conçues pour des applications modernes. Je pense que la partie de ces approches qui est valable est qu'elle oblige à une analyse plus détaillée des exigences connues, alors je pourrais autrement la donner.

Obtenir un bon ensemble de données avec lesquelles travailler est très difficile, même si vous avez un bon modèle. Mesurer la productivité est difficile. Les gens jouent à peu près n'importe quelle métrique.

J'ai cessé de l'utiliser parce que mon organisation est trop dysfonctionnelle pour bénéficier d'estimations logicielles mais j'ai une certaine considération pour le groupe Cost Xpert et leur outil; mais il est très coûteux et ne vaut probablement pas le coût et la courbe d'apprentissage pour la grande majorité des organisations.


0

Il est très difficile d'estimer les efforts et les coûts, mais si vous voulez quelque chose de plus précis, alors:

  • divisez HoursOfWork en 3 composants:

    1. meilleure estimation,
    2. estimation la plus probable,
    3. pire estimation.
  • supprimer EstimatedIddle.

Prenez note que tout ce qui prend plus de 8 heures entraînera une énorme erreur.


0

Ce que nous faisons normalement, c'est de diviser la portée complète du travail en modules / éléments majeurs qui pourraient être considérés comme des sous-projets. En d'autres termes, il s'agit des parties de travail que le client considère comme des parties distinctes du projet et que le client souhaite obtenir séparément.

Une fois cela fait, nous divisons chaque module en tâches, sous-tâches et sous-sous-tâches encore plus petites afin que chacune puisse être estimée assez facilement et l'estimation prenne de une à dix heures-homme. De cette façon, nous obtenons une ventilation détaillée de la portée du travail pour le projet.

La dernière étape consiste à répartir les tâches entre les jalons. Nous le faisons de manière à ce qu'après chaque étape, le client obtienne des résultats visibles. Cela aide à passer un jalon et à passer à un autre. Donc, finalement, nous obtenons quelque chose comme:

Module 1

    <ol>
        <li>
            Primary task 1 - 5 hrs
            <ol>
                <li>Subtask 1.1 – 3 hrs</li>
                <li>Subtask 1.2 – 2 hrs</li>
            </ol>
        </li>
        <li>
            Primary task 2 - 9 hrs
            <ol>
                <li>Subtask 2.1 – 1 hrs</li>
                <li>Subtask 2.2 – 2 hrs</li>
                 <li>Subtask 2.2 – 5 hrs</li>
            </ol>

Au départ, nous l'avons fait en utilisant simplement une feuille Excel. Mais il y a plus de deux ans, nous avons commencé à utiliser un outil logiciel pour cela. Il y a peu de produits similaires qui aident à le faire www.evenflow.com , www.swproposal.com et quelques autres. Je ne me souviens pas de toute la liste. Nous avons fait des recherches il y a longtemps. J'espère que cela peut aider.

La bonne question est de savoir comment estimer précisément. Il n'y a pas d'estimation correcte à 100% comme nous le pensons. La seule façon est de diviser la totalité du champ de travail en tâches aussi petites que possible. Les petites tâches que vous avez l'examen et l'analyse plus détaillée du projet que vous faites. De sorte que de toute façon augmente la précision.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.