Estimation du temps de développement

@admins/modos : Après un éclaircissement sur le chat, ce thread aurait plutôt sa place dans "Général Développement". S'il est possible pour vous de le déplacer ? Merci d'avance

Bonjour,

Je développe actuellement un client de newsgroups en Java avec une interface en Swing. Ce projet est réalisé à titre personnel, ce n'est pas un exercice d'école (je suis maintenant diplômé \o/) et n'est pas un projet professionnel.

Je cherche à savoir à combien de temps vous estimez la phase de développement dans sa globalité, dans le cadre d'un développement par une équipe ou en solo.

- Equipe :
Il n'y a qu'un développeur sur le projet, moi, donc pas de répartition des tâches ni de travail en parallèle. Néanmoins, je serais curieux d'avoir une estimation dans le cadre d'une équipe de quatre personnes par exemple.

-Fonctionnalités:
* Le soft utilise exclusivement des NZB. Pas de recherche manuelle dans les groupes, ni de chargement de la liste des groupes.
* On peut lancer plusieurs NZB successivement, ils sont mis en file d'attente, téléchargés, puis décodés (décodage YEnc exclusivement pour l'instant).
* Le téléchargement est multithreadé (10 threads dans mes derniers tests, mais ce nombre est bien entendu variable).
* La phase de décodage Yenc possède son thread dédié.

-Interface
L'interface graphique s'inspire fortement de celle d'AltBinz : http://www.altbinz.net/screenshots/g36051s130.jpg
Le composant principal de cette interface présente les fichiers à télécharger en les groupant par NZB. J'utilise une JXTreeTable pour avoir une "table arborescente".


Au niveau des librairies :
- Apache Jakarta -> Commons Net (NNTP)
- SwingX -> Extension de Swing, je l'utilise pour une JXTreeTable
- XStream -> sauvegarde de prefs et file d'attente en XML
- YDecode -> Décodeur YEnc
- JDom -> Parser le NZB (qui est en XML)
- Log4j


Petit lexique:
http://en.wikipedia.org/wiki/NZB
http://en.wikipedia.org/wiki/Usenet_...ary_newsgroups

Il est évident que l'estimation que je demande est à faire "au jugé" et en fonction des expériences de développement que vous avez eu précédemment, que ce soit en équipe ou en solo.
Volontairement, je ne donne pas l'avancement actuel du projet ni le temps passé dessus, je cherche à avoir un avis extérieur non biaisé par la connaissance de ma progression.

Il y a énormément de choses à prendre en compte. Estimer correctement un projet demande beaucoup d'expérience.
Il faut ajouter aussi les niveaux de compétences de chaque personne qui va intervenir sur le projet.
Chaque chiffre est sujet à discussion, selon si on se place côté concepteur, architecte, développeur, chef de projet ou client.
De plus, il est toujours difficile de chiffrer un tout petit projet car la marge de manoeuvre est faible si un problème surgit en cours de route.

Malgré tout, je me lance (chiffrage large, à vendre au client potentiel) :

• cahier des charges / étude architecture (écrire les algo, analyse des points difficiles) : 5 jours
• conception de la GUI sur papier : 1 jour
• développement + tests unitaires : 3 jours
• tests : 1 jour

Wow, alors autant je me doutais que je serais pas forcément très performant parce que j'apprends encore des tonnes de trucs en le développant, autant là 10 jours pour l'ensemble du projet ça me parait vraiment pas beaucoup :|
Surtout pour une estimation qui se veut large !

Par contre, tu précises pas si tu pensais à une équipe ou à un seul dev ?

Aussi, je n'ai pas précisé que je sépare fortement la partie graphique de la partie métier, d'une part parce que c'est une pratique de développement saine, d'autre part parce que je compte réellement séparer le métier et le réutiliser dans d'autres applis.
L'estimation que tu me donnes me parait extrêmement optimiste SI on se positionne dans le cas où le métier est déjà implémenté et utilisé comme librairie. C'est un peu comme si là seule chose qui restait à coder était la GUI.
Même maintenant que je connais les librairies et que j'ai déjà rencontré et traité une bonne partie des points difficiles, je ne pense même pas être capable de mettre la conception sur papier en 5 jours (ou peut être tout juste).

D'un autre côté, je me rends bien compte que faire une estimation est déjà difficile en temps normal et d'autant plus sur un projet qui n'est que brièvement décrit.

Et même niveau GUI c'est juste, surtout si l'on a les mains à mettre dans la JXTreeTable qui est un composant posant régulièrement problème (hacks, bugs Swing & cie)...


De plus il reste tout les éléments graphiques (icônes & cie) à trouver ou réaliser, monter un archi saine et pas tout développer à l'arrache.

Soit dit en passant la description initiale est vraiment légère pour pouvoir effectuer une estimation relativement fiable.

Aucune idée des dialogues à mettre en place, des différents écrans de l'appli, gestion des newsgroups demandant authentification et ainsi de suite.

Mais 3 jours me semble très très très léger comme estimation. D'autant plus que ça implique les tests unitaires à développer, lancer systématiquement.

Là pour moi c'est le meilleur moyen in fine de se mettre le client à dos (délais non respectés, produit à moitié fini, bugs non découverts...) et en être de sa poche aussi.

dinobogan: c'est un avis perso, mais quand la phase d'analyse prend autant de temps que la phase de développement, je m'inquiète parce que ca veux dire qu'à 50% du budget alloué et du temps alloué, on a pas encore une seule ligne de code.

Perso je suis plutot dans l'idéologie agile. Tu prend tout tes besoin, que tu met sur des petit cartons ou autre. Ensuite tu recherche dans tes carton le besoin qui te semble le plus rapide à mettre en place. Tu dit "ça, c'est 1" ou "ca c'est 2". Ensuite tu prend tout tes autres besoins et tu estime quelle difficulté il représentent par rapport à ton étalon que tu viens de déterminer (exemple, ça c'est 5x plus dur, ca c'est 10x plus long à faire).

Une fois ça fait, tu commence le développement, au bout de 2/3 jours, tu aura déjà une très bonne idée de "combien d'unités" ton équipe est capable de produire sur CE projet spécifique par jour. A partir de là et du nombre d'unités mesuré plus haut, t'as une bonne estimation (par expérience à 20% près) du délai du projet.

Maintenant, l'ennui pour les clients, c'est que ça nécessite de démarrer avant d'avoir une idée du budget, pas facile à vendre :aie:

Hum, c'est intéressant cette utilisation des méthodes agiles, je me garde ça dans un coin de cerveau.

Ceci dit, ma question portait plus sur "Combien de temps ?" plutôt que sur "Comment j'estime mon temps ?".

Pour moi, le but de ce projet est de faire valoir une expérience personnelle forte pour me différencier des autres ingénieurs qui n'ont "que" leur diplôme en sortant d'école. Le but secondaire étant de me faire plaisir en le développant ^^

Ce que je n'ai pas dit précédemment, c'est que le développement s'est fait sur plusieurs années, en plusieurs fois. La première fois j'ai travaillé dessus un mois (mais pas avec des horaires de boulot, en vacances), après je suis reparti from scratch parce que mon code était trop sale, etc...
Donc c'est un peu dur pour moi d'estimer le temps de développement total vu que ça s'échelonne sur deux ou trois ans. D'où ma demande d'estimation pour avoir un référentiel, même si ça n'est jamais qu'une estimation lancée un peu au hasard.

Je vais essayer de faire une description un peu plus détaillée mais j'ai peur de vite partir trop dans le détail.


L'objectif premier de ce projet est de télécharger un NZB. Si on fait une analogie avec BitTorrent, le fichier NZB l'équivalent du fichier torrent. C'est un petit descripteur XML qui donne les infos nécessaires à la récupération sur les NG. Un NZB décrit une liste de fichiers. Chaque fichier est composé de segments (ou articles). Ces articles sont en fait du texte encodé en YEnc, d'où la nécessité de décoder les segments par groupe pour recomposer les fichiers (version courte, 1 fichier = un groupe de segments).

En utilisation nominale, on a donc :
Etape 1 : Parser le NZB
Etape 2 : Télécharger les segments
Etape 3 : décoder les segments pour recomposer les fichiers

En pratique, la liste de segment est triée pour que les groupes de segments soient contigus dans la file d'attente. Ce qui veut dire que dès qu'un groupe de segment est terminé, le decodage est lancé et le téléchargement du groupe suivant commence (en parallèle). Ce qui m'amène donc aux threads.

Threads:
-EDT (Swing, pas de surprises)
-SingleThreadExecutor pour parser les NZB, executer commandes longues, ...
-SingleThreadExecutor dédié au décodage Yenc
-FixedThreadPool qui effectue les téléchargements et consomme la file d'attente de segments.

Interface :
Actuellement, ça ressemble à ça : http://img842.imageshack.us/f/newzmotte.png/
La partie supérieure (centrale) de l'interface présente la file d'attente (sous forme de fichiers et NZBs). Cette vue est équivalente à la file de segments maintenue dans le métier et consommée par le ThreadPool
La partie inférieure "monitore" les connexions actives. La colonne "progression" contiendra des JProgressBar, comme la colonne "Status" dans la JXTreeTable.

Voilà, je pense qu'en recoupant avec les infos du premier message du thread, ça doit donner une meilleure vue du projet :)