Discussion :

[hegros]

bonjour


Tout est dans la question. Je cherche une méthode ou démarche pour estimer les charges en jour homme d'un groupe/package de use case


J'aimerais avoir vos retours d'expériences, une méthode qui me parait coller avec les éléments qu'on posséde en fin d'expression des besoins c'est la méthode des 10 paramètres. Les points de fonction sont aussi intéressants mais cela ne donne pas vraiment de charge et encore moins de délai.

Voilà ce post est libre pour discuter des estimations initiales d'un projet partant sur un modèle de use case.

[souviron34]

on en a déjà discuté ailleurs , ce me semble...

Mais en gros, il n'y a pas de réponse toute faite... (c'est justement à cause de ce genre de tentative d'approche "systématique" que les méthodes style Waterfall sont de plus en plus remplacées par d'autres, les estimations n'ayent plus rien à voir avec la réalité).

Cela dépend :

• du style de projet
• de la taille du projet
• du style de contraintes
• du style de l'équipe
• de l'expérience de l'équipe
• des inconnues au départ
• .....

Faire l'estimé de la fabrication d'un site Web de 8 pages avec une petite BD, un programmeur et un graphiste, n'a rien à voir avec faire l'estimé de la fabrication d'un logiciel de backup sécurisé de 500 téraoctets généraliste, ou d'un logiciel de pilotage automatique de l'Airbus A380.

Même pour les cas style Airbus (et d'ailleurs il suffit de voir les dépassements de délai et de budget), 1000 personnes ne font pas 1000 fois le travail d'une personne, ce qui malheureusement est encore trop souvent répandu comme manière d'estimation..

Les points de fonction donnent une certaine idée, mais encore une fois pas la panacée : 2000 fonctions triviales faites par programmeur moyen, par rapport à 20 complexes faites par un spécialiste pointu de la question... les 20 peuvent prendre 4 fois plus de temps à faire que les 2000...

[hegros]

du style de projet
de la taille du projet
du style de contraintes
du style de l'équipe
de l'expérience de l'équipe
des inconnues au départ

la méthode MCP prends en compte ce type de paramètre il me semble


les points de fonction c'est intéressant qu'à partir du moment où tu l'utilises pour plusieurs projets car comme tu dis souviron la méthode est fortement liée à un paramètre de productivité/compétence d'équipe et surtout elle ne s'applique qu'à de l'informatique de gestion... elle a trop de limite encore je trouve bien qu'elle est évoluée.


Si vous avez des approches à partir de use case, modèle du domaine métier(diagramme de classes) et activité pour faire les estimations vous pouvez y aller à la bonne heure !

[souviron34]

les points de fonction c'est intéressant qu'à partir du moment où tu l'utilises pour plusieurs projets car comme tu dis souviron la méthode est fortement liée à un paramètre de productivité/compétence d'équipe et surtout elle ne s'applique qu'à de l'informatique de gestion...

d'où tires-tu ça ??

Pas du tout, cela a été appliqué partout (la NASA l'a utilisé, entre autres).

Mais c'est buggé, dans le principe même (voir ci-dessus)

[hegros]

d'où tires-tu ça ??

Pas du tout, cela a été appliqué partout (la NASA l'a utilisé, entre autres).

Mais c'est buggé, dans le principe même (voir ci-dessus)

Sur une page qui faisait le point dessus.

Dans les limites il y avait effectivement le fait qu'elle s'applique pour l'informatique de gestion puisqu'elle ne prends pas en compte le matériel, l'environnement/architecture technique, la complexité des algortihmes...c'est une méthode indépendante de tout cela c'est ce qui en fait un avantage et un inconvénient.

Il faudrait que je retrouve l'article pour te donner l'auteur et la date de parution mais c'était plutot recent 3-5ans, peut être la méthode a évoluée depuis...

[souviron34]

Il faudrait que je retrouve l'article pour te donner l'auteur et la date de parution mais c'était plutot recent 3-5ans, peut être la méthode a évoluée depuis...

change de bouquin ou d'auteur, alors

la méthode des points de fonctions a plus de 40 ans !!!

Et justement, un des critères de la faillite des méthodes traditionnelles, avant l'introduction des méthodes dites "agiles", a été le bilan y compris par rapport à ce que faisait la NASA et d'autres grosses entreprises industrielles...

Donc si ton auteur dis que ça n'a été utilisé que dans la gestion, ne croit rien de ce qu'il dit

[hegros]

change de bouquin ou d'auteur, alors

la méthode des points de fonctions a plus de 40 ans !!!

je sais bien mais en 40 ans elle a quand même bénéficier d'énormément de mise à jour et heureusement !

Donc si ton auteur dis que ça n'a été utilisé que dans la gestion, ne croit rien de ce qu'il dit

Tu as lu mes derniers arguments ? Cela ne prends pas en compte certains aspects comme la complexité des algorithmes que tu peux retrouver dans les applis autres que gestion.

Attends que je retrouve l'auteur avant de te prononcer car il me semble qu'il s'agit d'un des fondateurs/concepteurs de la méthode

[wiztricks]

La précision des UC est (à mon sens) insuffisante pour estimer de facon fiable (à moins de 10% près) le coût du projet sauf si vous avez déjà une bonne expérience dans la réalisation de projets similaires (et la chance de pouvoir vous appuyer sur les expertises qui vont avec).

Pourquoi : a priori, le découpage en composants n'a pas encore été fait et que le choix des technologies (faire ou intégrer) reste, à priori, à faire. Cela peut être sensible dans l'estimation des coûts puisque plus de code = plus de tests = plus de bugs = plus de rework.

"Similaires" signifiant (entre autres) une bonne connaissance des technologies à intégrer et une certaine expérience sur ce que cela signifie côté développement, tests, environnements.

Les différences peuvent porter sur des aspects non fonctionnels: si vous avez en région parisienne un equipe de développeurs qui a une bonne expérience n'est pas forcément transposable pour un projet en Allemagne ou à Toulouse ;-(

=> Personnellement je préfère la méthode des FP mais elle ne donne de bons résultats qu'en fonction de l'expérience acquise dans des projets similaires.

Cela admis, ce n'est pas parce que deux projets se ressemblent qu'ils sont identiques... Votre expérience vous permettra d'être confiant sur les coûts de réalisation de certaines parties et complètement nébuleux sur d'autres. En fonction de la taille du "nébuleux", c'est un problème de prise de risque.

Si le nébuleux est trop important (ie, le projet est tellement original que les compétences internes et sur le marché sont rares), il faudra prototyper.

Nota estimer les coûts de façon fiable signifie maîtriser les inconnues et ne peut que reposer sur l'expérience et les équipes (après on peut formaliser cela avec des méthodologies comme FP ou autre).

Dans ce cadre, les méthodologies de réalisation de type cascade ou agile ne sont d'aucune aide: leur propos est plutôt côté "gestion du changement".

-W

[hegros]

La précision des UC est (à mon sens) insuffisante pour estimer de facon fiable (à moins de 10% près) le coût du projet sauf si vous avez déjà une bonne expérience dans la réalisation de projets similaires (et la chance de pouvoir vous appuyer sur les expertises qui vont avec).

Effectivement. En fait je cherche à obtenir une estimation globale du projet en jour-homme à partir des modélisations obtenues pendant la phase de définition des besoins, j'ai parlé de la méthode MCP ou des 10 paramètres si tu connais ou as utilisé.

A partir de cette estimation globale je peux utiliser des facteurs de projection pour préciser les charges/délais de chaque phase du projet (conception, développement...)


Ensuite dans ma démarche je réestime à la fin de chaque phase. Et c'est bien en fin de conception détaillée que je peux estimer de façon précise et fiable le développement.


Pour le moment je me tatonne sur l'estimation gloable...

Pourquoi : a priori, le découpage en composants n'a pas encore été fait et que le choix des technologies (faire ou intégrer) reste, à priori, à faire. Cela peut être sensible dans l'estimation des coûts puisque plus de code = plus de tests = plus de bugs = plus de rework.

Je ne sais pas si c'est cela mais un découpage structurel est fait, en tout cas il n'y a à priori pas de difficulté de l'établir à partir des UC. Le choix et l'architecture techniques étant déja connus.

=> Personnellement je préfère la méthode des FP mais elle ne donne de bons résultats qu'en fonction de l'expérience acquise dans des projets similaires.

Un peu comme les points de fonctions.

Nota estimer les coûts de façon fiable signifie maîtriser les inconnues et ne peut que reposer sur l'expérience et les équipes (après on peut formaliser cela avec des méthodologies comme FP ou autre).

Oui mais bon il faut bien partir d'une estimation globale et parfois on n'a pas le choix comme dans le cas de réponses à des appels d'offres par exemple il faut bien estimer le projet..

[wiztricks]

Ok, donc vous ne partez pas complètement de rien (ouf).

Vous connaissez donc les différentes phases de votre projet et vous avez une méthode plus ou moins empirique pour en estimer les charges.

Pour le moment je me tatonne sur l'estimation gloable...

C'est un projet à combien de M€?
Quelle est la fourchette à laquelle vous arrivez (au minimum, au maximum).
Quelle est la précision recherchée?

-W
PS: A part valider sous une autre forme cette estimation, je ne vois pas ce qu'apporteront MCD, 10 paramètres ou FP.

[hegros]

C'est un projet à combien de M€?
Quelle est la fourchette à laquelle vous arrivez (au minimum, au maximum).
Quelle est la précision recherchée?

pour le moment 0 euros puisque je n'ai pas encore fini la phase de définition des besoins.

-W
PS: A part valider sous une autre forme cette estimation, je ne vois pas ce qu'apporteront MCD, 10 paramètres ou FP.

Les 10 paramètres cela permet juste d'estimer une charge et un délai en fonction de parmaètres Genre nombre d'entité, nombre d'association, environnement technique, compétences équipes.... Cela m'apporte donc une charge en jour homme et un délai


FP je ne connais pas si tu as un lien utile

[wiztricks]

C'est un projet à combien de M€?
Quelle est la fourchette à laquelle vous arrivez (au minimum, au maximum).
Quelle est la précision recherchée?

pour le moment 0 euros puisque je n'ai pas encore fini la phase de définition des besoins.

Même imprécis, tu dois avoir un ordre de grandeur avec un min et un max.
L'ordre de grandeur donne une idée de la complexité et le min et le max donnent une idée sur les incertitudes qu'il faut adresser (et du marteau à employer pour le faire).

Citation:
Envoyé par wiztricks Voir le message
-W
PS: A part valider sous une autre forme cette estimation, je ne vois pas ce qu'apporteront MCD, 10 paramètres ou FP.

Les 10 paramètres cela permet juste d'estimer une charge et un délai en fonction de parmaètres Genre nombre d'entité, nombre d'association, environnement technique, compétences équipes.... Cela m'apporte donc une charge en jour homme et un délai

yup mais fondamentalement tu pars d'un MCD ou d'un MOT au sens Meurise (ou d'un d'une sorte de diagramme de classes au sens UML): si tu en es aux UC, il faut un peu avancer pour appliquer cela.
Après il faut "pondérer" et là c'est "magique" car on peut se planter de 500%.

FP je ne connais pas si tu as un lien utile

Pardon de m'être laissé allé à penser anglais en écrivant cela: FP = PF = point de fonction. Comme pour "10 paramètres" difficile d'appliquer cela aux UC directement: il faut encore modéliser pour arriver à quantifier la complexité.
Mais comme pour les "10 paramètres", si la mesure de la complexité n'est pas trop fausse (çà dépend du modèle) sa traduction en "coûts/délais" dépend de facteurs externes difficile à pondérer (sans les retours d'expérience).

- W

[hegros]

Même imprécis, tu dois avoir un ordre de grandeur avec un min et un max.

j'ai bien un ordre de grandeur min/max dans ma tete pour le moment, c'est assez délicat les couts tout comme les estimations il en existe plusieurs desquels tu parles, matériel, logiciel, personnel ?

yup mais fondamentalement tu pars d'un MCD ou d'un MOT au sens Meurise (ou d'un d'une sorte de diagramme de classes au sens UML): si tu en es aux UC, il faut un peu avancer pour appliquer cela.

super ! j'ai déja des premiers diagrammes de classes pour chaque use case j'imagine que quand j'assemblerais ces derniers en éliminant les redondances cela me suffira suffisant pour estimer la charge de l'ensemble de mes packages

Après il faut "pondérer" et là c'est "magique" car on peut se planter de 500%.

Pour te donner quand même un ordre de grandeur c'est un projet de 6-12 mois homme pour le domaine étudié. 500% de plantage je pense que d'ici là ils me flanqueront à la porte

il faut encore modéliser pour arriver à quantifier la complexité.

C'est ce que j'ai fais en réalisant des uses cases. C'est bien une modèlisation métiers de ce qu'il faut réaliser qui a été fait.


Le titre est peut-être un peu trompeur ce n'est pas à partir des uses cases que je cherche une façon d'estimer les charges mais à partir de l'ensemble des diagrammes utilisés pendant la phase de définition des besoins soit uc, dc et éventuellement ds

[wiztricks]

6 a 12 mois hommes faisant travailler 3-7 personnes signifient 700 a 1400 JH.

Vous avez déjà répondu à nombre de questions et le projet est suffisament petit pour que vous soyez en mesure de décliner les différentes tâches à réaliser dans chaque phase.

Vous devez donc pouvoir estimer les charges de chaque tâche et donc coûts et délais de facon +/- précise.
Si cela demande encore un peu de travail de mise en forme, je ne vois pas quelles sont les informations manquent.

Dit autrement, je pense que vous être trop avancé pour estimer le projet avec une méthode de type FP: vous disposez déjà de données plus précises.
Note: mais rien ne vous empeche de le faire pour "calibrer", ou estimer d'une autre façon.
-W

[hegros]

Beh je dispose surtout de diagramme UML organisé en package

Etant donné qu'il s'agit de la dbs générale du système maintenant pour chaque package je voudrais estimer (vue rup) la phase de definition des besoins, analyse/conception et construction/transition.

de préférence une méthode algorithmique...

[Invité]

Bonjour,
je viens de tomber sur votre discussion qui m'intéresse, même si je ne suis pas un spécialiste des charges de projets.

Je ne connais pas la méthodes des 10 paramètres, toutefois en regardant (très) rapidement, j'ai l'impression que cela s'approche de "Estimation of Effort Based on Use Cases".

Dans une vie antérieure, nous avons testé cette approche afin de pouvoir être en phase avec notre modélisation [UML].
Nous l'avons testé sur plusieurs projet apostériori, et cela s'avère assez proche, bien que comme toute estimations, certaines parties sont toujours au doigt levé.

Pour tester, vous pouvez récupérer sur le net en cherchant "EZEstimate".

[hegros]

Merci pour l'information il va me falloir regarder cela de plus près

Pour la méthode des 10 paramètres je l'ai utilisé parce que justement elle me semble la plus adaptée. En effet vous définissez les 10 natures d'éléments (la modélisation UML est de grande aide) qui sont en gros : nombre d'entités, nombre de relation, nombre d'écran, nombre de condition/événement.... ce qui donne un résultat CPX

Ensuite vous définissez un facteur de correction lié au contexte de réalisation (fiabilité du système, puissance du langage, besoins connus des utilisateurs...) qui donne un résultat CPR ?

Ensuite via une formule genre CPX (1+CPR) vous obtenez une charge en jours homme pour la réalisation. Ensuite (mais là c'est de ma personnalisation) j'utilise ce résultat final pour faire des projections sur le découpage en phase du projet.


Voilà si tu as des liens vers des sources claires et intéressantes sur EZEstimate

[hegros]

Tu parles peut-être de cela jack http://www.xpdian.com/Usecasebasedes...n.html#Topic78

Le problème c'est que comme pour les points de fonction il faut avoir déja quelques expériences pour affecter des poids au UC. En prenant les valeurs standard sur un projet estimé les décalages sont trés trés important (sursurrestimé)