Ben elle est basée sur l'etude statistique de x millions de lignes de code et utilise le nb de lignes de code pour déterminer l'effort à fournir en jour homme pour finir le programme.
Malheureusement ce travail a été fait pour des langages de type cobol. Dés que tu y mets du graphique on patauge dans le flou et je te parle meme pas du J2ee et autre .net. Du coup l'estimation de charge dans un projet et bien c'est au pif (en gros 1ere_estimation * 2 + 30%).
Jacques printz parle du pb dans un de ces derniers bouquin et il lui faut 200p pour fournir quelques clés mais je n'arrive plus à trouver la reference zut.
A+
A rajouter à la liste Coûts et durée des projets informatiques : Pratique des modèles d'estimation chez Hermes
Pour les auditeurs du CNAM, un reduc sur cet ouvrage est possible sur présentation de sa carte dans la librairie de l'editeur située proche Gare St-Lazare (si je me souviens bien)
La méthode COCOMO m'a toujours semblée inutilisable car elle est basée sur des statistiques de projets assez conséquents mais surtout qui commencent à dater.
Depuis on a fait pas mal de progrès en informatique et les programmes ne se concoient plus de la même manière. C'est, en outre, une méthode extrèmement difficile à mettre en place. L'expérience du chef de projet joue beaucoup (plus encore avec COCOMO).
La méthode des points de fonction me parait plus adaptée aux projets d'aujourd'hui.
Je crois que c'est Alan Cox qui évaluait le temps à coder une fonctionnalité dans le noyau avec une règle assez simple:
Temps_total = Temps_que_je_pense_passer_à_coder_la_fonctionnalité * 2 + 10%
Un de mes anciens collègues était dans la même estimation :
"s'il te faut 3 jours pour faire ceci, dis qu'il te faut 6 jours pour le faire, car ça merdoie toujours"...
# Y'a un truc qui m'étonne quand-même
Posté par mmMMOoooOMMmm . Évalué à 2.
"2. Il faut toujours le même effort pour écrire un nombre donnée de lignes de programme, quelque soit le langage de la même génération utilisée."
http://www.alaide.com/dico.php?q=COCOMO&ix=443(...)
[^] # Re: Y'a un truc qui m'étonne quand-même
Posté par yapacpuca . Évalué à 3.
Malheureusement ce travail a été fait pour des langages de type cobol. Dés que tu y mets du graphique on patauge dans le flou et je te parle meme pas du J2ee et autre .net. Du coup l'estimation de charge dans un projet et bien c'est au pif (en gros 1ere_estimation * 2 + 30%).
Jacques printz parle du pb dans un de ces derniers bouquin et il lui faut 200p pour fournir quelques clés mais je n'arrive plus à trouver la reference zut.
A+
[^] # Re: Y'a un truc qui m'étonne quand-même
Posté par Nico . Évalué à 2.
A rajouter à la liste
Coûts et durée des projets informatiques : Pratique des modèles d'estimation chez Hermes
Pour les auditeurs du CNAM, un reduc sur cet ouvrage est possible sur présentation de sa carte dans la librairie de l'editeur située proche Gare St-Lazare (si je me souviens bien)
# Pifomètre
Posté par _seb_ . Évalué à 3.
Depuis on a fait pas mal de progrès en informatique et les programmes ne se concoient plus de la même manière. C'est, en outre, une méthode extrèmement difficile à mettre en place. L'expérience du chef de projet joue beaucoup (plus encore avec COCOMO).
La méthode des points de fonction me parait plus adaptée aux projets d'aujourd'hui.
Je crois que c'est Alan Cox qui évaluait le temps à coder une fonctionnalité dans le noyau avec une règle assez simple:
Temps_total = Temps_que_je_pense_passer_à_coder_la_fonctionnalité * 2 + 10%
[^] # Re: Pifomètre
Posté par XHTML/CSS inside (site web personnel) . Évalué à 3.
"s'il te faut 3 jours pour faire ceci, dis qu'il te faut 6 jours pour le faire, car ça merdoie toujours"...
[^] # Re: Pifomètre
Posté par jahrynx . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.