Discussion :

[BugFactory]

Bonjour.

Voici le problème.

On vous demande de reprendre / modifier / faire évoluer une application existante. Le développeur originel a émigré au Tibet et s'est fait moine boudhiste pour échapper à votre patron actuel et est donc injoignable.

Entre la documentation absente, ou au contraire abondante mais rarement pertinente, comment faites-vous pour reprendre une application / SI / ce que vous voulez existante?

Seule règle : tous les gens qui y comprenaient quoi que ce soit sont partis avant votre arrivée. Vous ne pouvez donc rien leur demander, et vous ne pouvez pas non plus partir pour le Tibet.

C'est pour moi le plus pénible, et je pense souvent que je ferais mieux de repartir de zéro. Je me demande donc si vous connaissez des méthodes efficaces.

[nako]

Salut, si le départ pour le Tibet est impossible,
alors je te conseille :
de partir du plus haut pour descendre vers le plus bas.
Essaie de regarder les gros modules/classes/packages composant ton application.
Essaie de comprendre les relations entres eux (inclusions, héritage, utilisation, etc ...)
Une fois que tu auras fait ça, descend dans chaque module/classe/package et essaie de repérer les fonctions/méthodes etc ...

Selon le langage de l'application, tu as des outils de "reverse engineering" qui peuvent t'aider à faire ça.
bon courage A+

[Invité]

Bonjour,

Pour commencer, je suis heureux de voir que je ne suis pas le seul extrémiste dans mes exemples
quand je parle à mes collègues sur la documentation.

Plus sérieusement, concernant ton problème :

2 approches s'offrent à toi (je vais simplifier pour ne pas écrire un gros pavé)

1° Etudier l'existant via une méthode plutôt "merisienne".
Ceci a bien entendu divers avantages:
- Comprendre le système existant,
- T'aproprier l'existant et "cracher" la doc qui va avec.
- Commencer à voir les pb qui peuvent exister et donc intégrer les modifications / évolutions que tu pourrais / devrais faire...

2° Reprendre tout à 0 : ceci a des avantages mais posent des pb :
- Tu dois tout refaire, c'est à dire, ne pas te baser sur l'existant, donc revoir tous les utilisateurs pour récupérer les processus métier,
les besoins / envies, etc... Ceci demande bcp de travail et surtout de la disponibilité des utilisateurs.
[Evidemment, si par "les gens qui y comprenaient quelque chose" tu entends les utilisateurs, tu n'a rien à faire car il n'y a pas de besoins :-) ]
Cette approche, étant plutôt de type "objet" (UP) puisqu'en général partir de rien a l'avantage de ne pas de focaliser sur le passé, et donc tu n'es
plus assujétie à des "préjugés".

J'oubliais quand même une troisième solution : Partir au Brésil (parce qu'au Tibet, il fait froid et tu pourrais te faire arrêter par les chinois)

Je ne sais pas si cela t'aidera mais au moins tu auras un point de vue !!!
CARPE DIEM

[BugFactory]

De bons conseils, malheureusement j'avais déjà pensé à la plupart d'entre eux.

Pourriez vous me donner les noms de bons outils de reverse engineering?

[ypicot]

Quand j'ai ce genre de délice qui arrive, je commence tout bêtement par faire un manuel utilisateur (très simplifié), ce qui me permet d'avoir une idée de la bête.

Ensuite (et ensuite seulement) je discute avec les utilisateurs pour savoir comment ils utilisent l'appli. Dans la pratique, cela donne "imaginez que je sois un stagiaire qui doit faire votre travail pendant les vacances. Expliquez-moi comment ca marche". Cela permet de faire le tour des branches mortes, des attentes et de compléter mon manuel.

C'est seulement après que je me plonge dans le code (généralement en me bouchant le nez. Visiblement la qualité d'écriture du code n'est pas un critère pour devenir moine boudhiste).

A partir de là, je peux prendre la décision de la réécriture complète, de la modification ou de l'achat d'un billet vers le Groënland.
Dans le pire des cas, je considère l'existant comme une maquette plus ou moins fonctionnelle de ce qu'il y a à faire.

"une solution n'est valable que dans un contexte donné"

Yvan

[Hauwke]

Bonjour,

Pourriez vous me donner les noms de bons outils de reverse engineering?

Quel est le langage utilisé par l'application éxistante?
Quel age a-t-elle? En effet, si elle "date" un peu je pense qu'il serait plus avantageux pour toi de la cloner en utilisant les derniers outils disponibles sur le marché. Tu obtiendrais un code "propre" au derniers standards avec ta doc et "ta façon de faire". Je présume que tu vas devoir assurer la maintenance à moins qu'il ne s'agisse d'un test initiatique à l'entrée dans les ordres... Penser "futur" te permettra de lever la tête du bourbier dans lequel tu sembles te trouver.
"Les pieds dans la m.... et la tête dans les nuages", les deux mamelles du dev.
Cordialement,
Hauwke

[ypicot]

D'accord avec Hauwke, mais en plus

"Les pieds dans la m.... et la tête dans les nuages", les deux mamelles du dev.

me parait extrèmement juste pour la reprise de bien des applis (et accessoirement m'a fait travailler les zygomatiques de façon violente pendant 5 min)

Yvan

[BugFactory]

Alors je note ... Brésil, Groenland...

Merci pour tous ces conseils, ça me donne quelques idées sur la façon de commencer... mon prochain projet, parce qu'il est trop tard pour celui-ci.

Pour les outils de reverse engineering : il s'agit d'une application J2EE. Cependant, je cherche aussi des outils pour des projets futurs qui utiliseront peut-être d'autres frameworks / langages.

Quand j'y pense, c'est tout de même surprenant. Reprendre une application existante est un très gros travail, mais il n'existe aucune méthodologie systèmatique pour celà alors qu'il en existe pour la création d'applications nouvelles, ce qui est en fait plus rare.

[Invité]

Quand j'y pense, c'est tout de même surprenant. Reprendre une application existante est un très gros travail, mais il n'existe aucune méthodologie systèmatique pour celà alors qu'il en existe pour la création d'applications nouvelles, ce qui est en fait plus rare.

Ce n'est pas tout à fait vrai.

Merise est plutôt fait pour cela puisque tu pars d'un existant.
Alors que le RUP / 2TUP / UP en général part d'une nouvelle application.

Je me rappelle, lorsque j'ai passé mon DESS (il y à 2 ans, en reprise d'étude par le fongécif... on s'en fiche mais cela me permet de le placer !!) sur la partie merise, j'ai eu la question : "si on vous donne un projet sur une nouvelle application, avec merise comme méthodo, que faites vous ?"
Et évidemment j'ai eu l'inverse de la question pour l'objet - avec processus RUP - "comment vous faites pour les anciennes applis ...."

En espérant que ton futur projet sera plus facile :-)

CARPE DIEM

[Eowyn]

Rien de bien nouveau à proposer... mais je pense que les use cases sont un bon moyen de se plonger dans les affres de l'appli.
J'ai dû le faire un certain nombre de fois (reprise d'une appli. et nouveaux développements à poser dessus), demander au user le comment il fait et surtout comment il ne fait pas (ça je fais pas parce que ça plante, là je passe par là parce que sinon je peux plus imprimer, etc...)

et si ton moine est sympa... il a dû commenter un peu son code, non ?

"Il n'y a qu'une doc qui soit toujours à jour, c'est le code !"
dixit un de mes développeur

Sinon, je propose la Namibie pour l'exil... désert pour le chaud, côte atlantique pour le frais !

[BugFactory]

Ok, merci pour ces pistes, je mets le tag résolu. Au revoir!