Rétro-engineering Excel : Règle de gestion

Dans le cadre d'un projet de rétro engineering, je dois traduire le code VBA sous forme de règles des gestion.
Le but étant de pouvoir redévelopper l'outil dans un autre langage.

Sprd0 = vPx(K, 6)

If vIndex(K, 7) = "ML" Then
Sprd1 = vIndex(K, 3)
sContrib = vIndex(K, 7)
ElseIf vIndex(K, 7) = "Vista" Then
If vSource(K, 1) = "Spread" And vSource(K, 2) = "Fixe" Then
sContrib = vSource(K, 2)
Else
Sprd1 = vIndex(K, 3)
sContrib = vIndex(K, 7)
End If
ElseIf vSource(K, 1) = "Spread" And vSource(K, 2) = "Fixe" Or vSource(K, 2) = "" Then
If vIndex(K, 3) = "" Then
Sprd1 = Sprd0
Else
Sprd1 = vIndex(K, 3)
End If
sContrib = vSource(K, 2)
Else
Sprd1 = Sprd0
End If

Comment traduiriez vous cela ? Avec un schéma ? Un tableau ? En français ?
En traduisant d'où provient la source des variables j'arrive à quelquechose comme cela :
Sprd0 = BondPx.SpGovt

Si Index.Source = "ML" Alors
Sprd1 = Index.Spread
sContrib = Index.Source

Si Index.Source = "Vista" Alors

Si Source.type = "Spread" Et Source.Contrib = "Fixe" Then
sContrib = vSource(K, 2)

Sinon
Sprd1 = Index.Spread
sContrib = Index.Source

Si Source.type = "Spread" Et Source.Contrib = "Fixe" Ou Source.Contrib = "" Alors

Si Index.Spread = "" Alors
Sprd1 = Sprd0

Sinon
Sprd1 = Index.Spread
End If
sContrib = Source.Contrib
Sinon
Sprd1 = Sprd0

Merci pour votre aide.

Bonjour,

La première étape consisterai à établir quel est le besoin de l'outil. Quels sont les meilleurs moyens (techniques et humains) pour arriver à répondre à ce besoin.

Commencer par une analyse fonctionnelle de l'outil. Ca peut débuter par des copie d'écran, les interfaces de saisie, et surtout les états de restitution de l'information.
Effectuer un schéma des flux de données de cet outil peut être une bonne idée pour voir comment interagissent les différents écran du programme.
Essayer de vous appuyer également sur l'expérience des utilisateurs qui peut être très bénéfique.

Lorsque vous aurez cerner le rôle de chaque écran, de chaque fonction, de chaque bouton du programme vous serez à même d'écrire les règles de gestion (cahier des charges en gros).

Pour les calculs complexes c'est intéressant de se plonger dans le code pour pouvoir détailler le calcul.

Un autre point à définir,une fois l'analyse fonctionnelle étudiée,serait l'envergure du projet.
Combien de client ? Quel est la source de donnée (Bdd ? feuilleXLs ? autres..) ? Quel moyen de restitution de l'information (Crystal ?) ?
Ceci vous permettra de définir si il vous faut recréer un MCD et si il faut orienté l'appli vers un client lourd / léger...

Je pense qu'il est inutile de symboliser graphiquement toute la structure du code. A moins que l'on vous ai donné juste une partie de code à décortiquer ...

Edit : Au final je n'ai pas répondu à la question :)
Comment symboliser cela ?
-Schéma des flux
-Modèle conceptuel de traitement
-Modèles conceptuel des données.
- Cahier des charge en francais avec les règle de gestions et description des calcul.

Ce sera déjà une bonne base pour commencer ^^

Merci.
J'ai déjà passé la première étape.

Analyse des fonctions principales, diargrammes de flux.
J'en suis donc au point où je cherche à rédiger les règles de gestion.
Le but est de 'migrer' certaines fonctions de l'outil dans un autre langage.
L'outil de base est développé en vba Excel.

Mon problème est plus de savoir comment modéliser ces règles de gestion (cf code vba plus haut).

Perso j'écris toujours mes règles de gestion en francais (avec les fautes d'ortographe que cela comprend ! :yaisse2:).

Par exemple :
Barre d'adresse : En cas de saisie d'une URL par l'utilisateur dans cette textbox, cela entraine l'ouverture de la page web associée à cette adresse dans le cadre de restitution du navigateur.
Le fameux QQOQC (Qui? Quoi? Ou? Quand? Comment?)
On peux imaginer ces règles sous forme d'un tableau. Cause / Effet / Conséquence / Evènement peuvent être des rubriques de ce tableau.

Si vous devez 'purement' migrer des fonctions (copier / Coller en gros) le plus compréhensible pour un développeur sera un algorythme (tel que vous le présenté dans la seconde partie de votre message).
Ceci à le mérite d'être compréhensible par n'importe quel développeur, venant de n'importe quel horizon.
Commenté un maximum afin que le développeur ne se pose pas la question de savoir pourquoi il doit écrire tel ou tel partie de code.

--> En même temps c'est vraiment mâcher le boulo au dév :D

@++ bon courage