Discussion :

[levolutionniste]

Bonjour, j'ai un logiciel développé sous windev. Et presque 5 clients. Jusqu'ici, pour chaque nouveau client, je faisais une copie du projet et je l'ouvrais sous windev comme un nouveau projet. Mes clients pourraient bien monter à 20 d'ici 2ans.

1.Est-ce là une bonne manière de créer un nouveau projet à partir d'un projet existant? Sinon comment faire?

Je pense que cela pourra être lourd pour la suite notamment lors des ajouts des fonctionnalités communes ou de la soustraction des fonctionnalités d'une version à l'autre; et lors des évolutions de Windev (V17 à version 21 par exemple) où il faudrait migrer tous les projets un par un. Bref je pense que c'est une mauvaise pratique que j'ai adopté là.

2. Windev propose-t-il des mécanismes de gestion des versions par client? (du genre un unique projet avec toutes les fonctionnalités et la possibilités d'activer ou de désactiver une ou telle fonctionnalité en fonction d'un paramétrage par exemple au lancement de l'application quoique cela sera complexe une fonctionnalité incluant bien souvent, de nouvelles fenetre, champ de saisie, bouton, etat, requete, etc.)

Ma gestion actuelle:
Dans la version initiale (V1), j'ai le logiciel par défaut

Dans la version 11, je modifie la logique d'une fonctionnalité principale à l'application (IHM, requete,etat)
Dans la version 12, je modifie la logique d'une fonctionnalité principale à l'application (IHM, requete,etat) mais je n'ai pas besoin de la modif de la V11 donc je me base sur la V1
Dans la version 13, je modifie la logique d'une fonctionnalité principale à l'application (IHM, requete,etat) mais je n'ai pas besoin des modifs des V11 et 12 donc je me base sur la V1

PLus tard un client demande une nouvelle spécificité, je trouve que tout de même son besoin est assez proche de la V12 donc je me base sur la v12 et je créé la version 121.

Mais après, il s'avère qu'un autre client a un besoin proche de la V121 mais sans les modifs de la V12. Du coup je dois me baser sur la V121 et "dé-programmer" les apports de la v12 et donc, refaire des tests pour m'assurer que tout fonctionne bien quand même après suppression des fonctionnalités apportées par la V12.

Bref voilà mon dada. L'avantage de cette méthode c'est que si un client veut un update, j'ai pas à réfléchir longtemps: j'ouvre le projet qui porte son nom, j'ajoute la modif sans vérifer que le nouveau code est compatible avec toutes les versions (les autres clients).

L'inonvénient comme je le disais c'est principalement : les upgrades de l'IDE sur chaque projet le cas échéant et la complexité à supprimer, dans une version fille, une fonctionnalité qu'on a passer du temps à ajouter dans la version parente. Souvent le même temps finalement.

L'inconvénient d'un projet unique, je suppose c'est la complexité des if/Switch etc à mettre en oeuvre sur chaque fenetre à ouvrir, si oui ou non il faut afficher un bouton, pour choisir la requete à exécuter, l'état à ouvrir, etc... (j'imagine de multiples if fonctionnalitésX et ou fonctionnalitésY et/ou fonctionnalitésZ,etc est active)

Alors, quelle est votre expérience? Qu'en pensez vous? Que me conseiller vous?
Windev propose-t-il une solution pour cela? Si oui, laquelle?

Merci.

[Lo²]

Bonjour,

Pour ce qui est de créer un projet par client, ben j'avoue que je n'aurais jamais pensé à le faire... bonjour la maintenance (même que 5 clients) !
Windev propose le GDS, qui permet de gérer le versionning (branche, report, etc).

Visiblement, chacun de tes clients a une application personnalisée mais l'application de base est la même pour tous.
Windev ne propose pas (enfin ça m'étonnerait) une gestion automatique d'un fonctionnement comme le tien, et pour moi, cela doit être géré par programmation.

[tbc92]

Comme LO², je suis contre l'idée de dupliquer les projets si la base est commune.
Je ne suis pas très chaud sur la gestion des branches par le GDS, mais c'est certainement parce que je ne maîtrise pas.

Effectivement, tu te retrouves avec tout un tas de code à chaque ouverture de fenêtre. Mais ça peut être très raisonnable.
Tu peux utiliser par exemple les groupes. Tu associes différentes champs à un groupe, et dans le code, tu dis groupe_1..visible = faux.

Prend bien soin de nommer chaque groupe par la fonctionnalité qui correspond, et pas par le nom du client...

Il faut juste être discipliné. Soit tu choisis de mettre tous les groupes facultatifs en visible, et par le code, tu les rends invisibles. Ou tu les mets tous en invisibles, et par code, tu rends visibles ceux qui correspondent à ton client. Mais si tu panaches, c'est une difficulté supplémentaire.

Tu as parfaitement décrit l'avantage de ta méthode: si un client demande une modif, tu n'as pas à réfléchir... Oui, tu économises 10 minutes de réflexion à court terme. Mais sur la durée, tu vas payer cela au centuple.

[frenchsting]

Une solution partielle (que nous utilisons) est d'enregistrer qq part le nom du client utilisateur. Dans notre cas, c'est le code client qui est mis dans la bdd.

Certains menus, boutons,... sont affichés ou masqués suivant ce code. De plus, certains traitement différent suivant ce même code. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
//Export comptable
selon CodeClient 
cas "1" : ExportSage()
cas "2" : ExportCegid()
AutresCas : ExportCiel()
FIN

[Yusep]

Bonjour.
Une autre possibilité :
les composants internes, soit par fonctionalité, soit par client dans ton cas.
En combinant avec la solution de frenchsting tu dois pouvoir le gérer.

[tunizar]

Une solution partielle (que nous utilisons) est d'enregistrer qq part le nom du client utilisateur. Dans notre cas, c'est le code client qui est mis dans la bdd.

Certains menus, boutons,... sont affichés ou masqués suivant ce code. De plus, certains traitement différent suivant ce même code. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
//Export comptable
selon CodeClient 
cas "1" : ExportSage()
cas "2" : ExportCegid()
AutresCas : ExportCiel()
FIN

Bonjour,
Il est possible d'avoir plusieurs configurations dans un projet en utilisant ProjectInfo combiné
piConfiguration
Ainsi, il y aura l'association d'une configuration par client dans le même projet.

[levolutionniste]

Merci beaucoup pour vos éclairages.

[R&B]

Bonjour,

Il existe aussi les configurations de projet qui permettent de ne livrer à un client que ce dont il a besoin... et à conditionner le code comme l'indique tunizar avec cette fois ProjetInfo(piConfiguration).

Plus technique et pointu mais nettement plus adapté sur la durée : concevoir votre projet en composants internes et livrer/activer ces composants selon la configuration du client.
Pour ce faire il vous faudra un composant principal par grande fonctionnalité avec des entrées/sorties pour d'interfacer avec les composants dédiés aux spécialisation par clients. Un composant d'interface peut aussi s'intercaler entre le composant générique et les composants client pour contrôler les échanges.
C'est un travail d'analyse et conception préalable à vos développements qui a un coût mais qui peu à terme faire la différence dans votre capacité à produire rapidement des adaptations.

En complément, il est possible d'utiliser l'abonnement de procédure pour produire des surcharge à vos procédure qui pourront avoir un comportement adapter à tel ou tel client.

En bref, il existe de nombreuses possibilités a adapter à votre budget / compétence.