Pour un rapport dans ma boite, je dois comparer deux projets avec des stats comprehensibles par des non-techniciens.  
 
Il existe tout un tas de chiffres possibles et deja utilises dans l'industrie, et celui sur lequel je dois me baser c'est EN MOYENNE le nombre de lignes de Java pondues par personne et par jour. Il s'agit d'une moyenne, qui prend en compte TOUS les participants a un projet sur TOUTE sa duree. (Je sais que ca veut pas dire grand-chose, mais c'est comme ca )
 
Est-ce que quelqu'un aurait deja audité un projet avec ce genre de critères ? Pour cette stat précise, je cherche a savoir quelle est la valeur "moyenne" (10, 50, 100, 1000 lignes Java/homme/jour) pour un projet de plusieurs milliers de classes ?
 
PS : Pas la peine de me dire que c'est une stat debile, je le sais déjà

mais ces stats sont deb... euh s'cuse
 
Vous utilisez koa poor le suivi logiciel, l'archivage, gestion de projet dans votre boite ?
Parce ke brut comme ca tu va te faire ch****

C'est pour faire un etat des lieux limite a un instant t =>
 
find . -name "*.java" | wc -l

mais si tu veux avoir tes stats aux jours le jour et savoir combien de lignes java un gars a code
 
en plus si il y a plusieurs personnes qui travaillent sur le meme fichier la meme journee, ca va po etre simple d'attribuer un nombre de ligne a chacun ...
 
par contre si on a l'hypothese qu'un fichier appartient a une seule personne et ke c'est exclusiement elle ki le manipule => bcp plus simple

:lol::lol::lol::lol::lol:
 
Dit à ton boss qu'on est plus en 1960 et qu'en objet on compte le nombre de classes et pas le nombre de lignes.
 
Enfin j'espère que c'est une blague...

evode : pas au jour le jour, mais au jour precis ou le projet est livre en production. Peut importe qui a bosse sur quoi, c'est juste une moyenne.
 
FDS : oui et non : le nombre de classes n'est pas un critere "metrique" et objectif ... par exemple, j'ai deux projets dont l'un a 20 fois plus de lignes que l'autre, mais "seulement" 10 fois plus de classes ... que peut-on en conclure objectivement ? Rien. Par contre, si un projet est a 10 lignes de java/homme/jour et l'autre 150, tu peux commencer a chercher des reponses : les "lents" ont-ils surdesigné ? Les "rapides" ont-ils codé a font la caisse sans se soucier de l'analyse ? Les "lents" sont-ils tout simplement mauvais ? etc etc etc (c'est pas aussi naïf que ça en a l'air )
 
Bref, y'a personne qui fait de l'audit ou de la qualite en entreprise et qui pourrait me sortir des chiffres moyens ?

[edtdd]--Message édité par Gonzoide--[/edtdd]

Gonzoide: Très franchement je ne vois pas comment tu vas faire pour différencier des développeurs avec comme seul critère le nb de lignes de code qu'ils ont pondus.
Tu as raison le nb de classes n'est pas le seul critère à prendre en compte. Si on reprends ton exemple avec les 2 développeurs. Imagine que les 2 dev doivent utiliser des expressions régulière dans leur développement. Le 1er qui a pondu 10 lignes a d'abord cherché et trouvé sur le net une API pour gérer les exreg (NB: API qui sera présente dans la 1.4), du coup il l'a utilisé et le nombre de lignes qu'il a pondu est donc plus faible. Maintenant le 2ème qui code à fond la caisse ne prends même pas le temps de regarder sur le net et développe une petite API lui-même(nb de lignes plus important). Le 2ème développeur imposera la maintenance d'une API qui a déjà été développé ce qui est coûteux, même s'il a pondu énormément de lignes. Je ne parle même pas des jeux de test, de l'analyse...  
 
Le nombre de lignes n'a donc très peu d'intérêts à mon sens sans compter qu'il faudrait déjà définir ce qu'est exactement une ligne de code (commentaire, déclaration de variable...).
 
Après 3 ans d'objet (Java et maintenant également Smalltalk) je peux te dire que les critères les plus importants pour moi sont:
 
- Le développeur sait-il bien programmer objet (d'après plusieurs études beaucoup de développeurs C qui passent à C++ ne font pas vraiment de l'objet et prennent C++ pour une simple update du C). Est ce qu'il a le réflexe de regarder si qq'un a déjà fait ce qu'il veut faire.
 
- Le code est-t-il propre et donc maintenable. Si le code est difficilement maintenable les débugs et évolutions risquent d'être coûteux surtout si le développeur n'est plus dans la boîte (très fréquent avec le turn-over des SSII).
 
Bref, il y a plein d'exemples à donner pour affirmer que le critère du nb de lignes n'est pas le seul critère exploitable pour comparer 2 projets et encore moins avec un langage objet. Je pense que tu devrais proposer d'autre critères de comparaison plus réalistes. On te demande de faire de la mesure du logiciel, de mesurer la productivité, la qualité et donc de définir les compétences de chacun ce qui aura forcément un impacte sur le statut et le salaire du développeur ou du futur développeur qui bossera sur des projets de ta boîte et c'est donc pas sans conséquences.
 
Si ca peux t'aider il existe différentes méthodes pour mesurer un logiciel Hood(pour la prog objet), Cocomo (estimation des ressources à partir du nombre de lignes prévues), McCabe (mesure la complexité, nb cyclomatique). Même si la méthode Cocomo peut être intéressante pour toi, cette méthode ne me paraît pas adapté à la prog objet et en plus elle est assez lourde à mettre en oeuvre comme les autres d'ailleurs.  
 
Sur ce bonne chance