Discussion :

[bchass]

Bonjour,

Je cherche des docs sur les méthodes de détermintion les coût et les délais de réalisation d'un systéme d'information


je vous remercie

[ego]

recherches : points de fonction, cocomo

[bchass]

Merci bcp:

[djflex68]

Le gros problème c'est qu'il n'existe aucune méthode fiable pour déterminer les couts et les délais de développement...
Cocomo par exemple c'est pour estimer après la phase de développement en fonction du nombre de lignes de codes (donc ça a plus bcp d'intérêt) ...
Dans ce domaine on ne peut pas vraiment estimer, seule l'expérience sur de nombreux projets permet d'approcher un chiffre cohérent (dans ce contexte, les points de fonction peuvent répondre à une partie du problème). Malheureusement de nombreux dirigeants ont encore bien du mal à comprendre pourquoi en informatique qui est pourtant une science binaire et très carrée, on reste aussi flou et vague sur les estimations...
Malheureusement c'est pas près de changer !

[bruno_pages]

je suis bien d'accord avec djflex68, le temps de développement / maintenance est quelque chose d'éminemment flexible, quoi quon en dise c'est très lié au personnes elles-même (sinon comment certains d'entre nous pouraient justifier leur gros salaires ? ) et à l'environement de développement (je pense entre autre à certains outils tout aussi catastrophiques que chers).

Oui, Cocomo repose sur le nombre de lignes, et pas qu'un peu, dans un projet récent avec les paramètres utilisés c'était à la puissance 4 ! En plus il a fallut passer à Scade, et là il n'y a plus de lignes de code mais des planches ...

De toute façon qui n'a jamais vécu un truc du genre :

• le chef : combien ?
• vous : 5000 heures
• le chef : mais c'est pas possible, on a budgeter 3000 heures !

le premier qui répond non ... est sans doute un chef

[gillesch]

Bonjour.

Actuellement notre site développe essentiellement en C

Je cherche des données factuelles sur les gains potentiels liés aux langages objets (C#,VB.NET,JAVA...)

Merci d'avance.

[souviron34]

je vous fournirai demain (vu l'heure, c'est dans mes tiroirs,..) une conférence du SEI (Software Engeneering Institute) qui s'appelle "Le chemin vers l'Enfer est pavé d'estimés exacts"...

Mais en gros par expérience PRATIQUEMENT TOUT dépend des gens impliqués et du type de projet :

Pour les gens :

• connaissances, compétences, aptitudes, à discuter, à se remettre en cause, à apprendre, à travailler sous pression, à leurs rythmes, à leur indépendance....
  
• Mieux vaut une petite équipe de très bons qu'une grosse de médiocres..
  
• Mieux vaut un bon chef et 1 bon indien que 1 mauvais chef et 10 indiens moyens.

Pour les projets :

• est-ce déjà fait ailleurs ?
• est-ce de la recherche ?
• est-ce du développement pur ?
• y a t-il beaucoup de choses qui ne dépendent pas de l'info, mais dont l'info dépend (interfaçages, machines, lois, accords de groupes d'utilisateurs, statistiques non encore établies ...)
• y a t il beaucoup de choses non encore connues ?

Et encore beaucoup d'autres choses....


Et enfin, quelque chose qui est totalement négligé dans le développement et les délais :

au bout du délai, est-ce qu'on a bien le produit qui était envisagé au départ, et répond-t-il aux attentes (des utilisateurs, du marketing) ?

Très souvent un logiciel est dit "terminé" (analyse, développement, tests, tout marche et est fait et documenté)... mais ça correspond pas à ce que les utilisateurs attendaient (par exemple)... Et pour y arriver.... doubler le temps (au moins )...

Quant à la question sur les gains obtenus par l'utilisation de langages objets, il y a bien sûr des stats, mais de nouveau tout est lié aux compétences des gens.

Par expérience personnelle j'aurais tendance à penser : zéro gain. Quelqu'un de très compétent en langage non-objet fera mieux et plus vite un très bon logiciel que quelqu'un de moins compétent en langage objet..

[ego]

Globalement plutôt d'accord avec mon prédécesseur.
Cependant, le gros avantage des langages objets actuels est que l'on dispose de beaucoup de librairies prêtes à l'emploi pour faire des choses relativement complexes. A l'époque où je faisais du C (il y a près de 14 ans), on avait à inventer ces librairies là.
Mais tout ceci n'est pas totalement lié à l'aspect objet des langages objets.

Cependant, on arrive quand même, je pense, à faire mieux et plus vite certains trucs complexes en objet grâce aux mécanismes objet eux-mêmes.

Mais, globalement plutôt d'accord avec mon prédécesseur....