Marché : Comment les situations de défaillance du produit seront-elles gérées après une mise à jour du build ?
...
Jusqu'à présent, la bonne nouvelle est que l'entreprise développe, organise et soutient le marché et la vente des produits MQL5. Il y aura donc une lutte pour la qualité, mais qui la paiera de sa réputation et de son argent ?
Les questions sont très pertinentes. Et une solution doit être trouvée. J'ai déjà une suggestion.
Par exemple, vous pourriez faire ce qui suit. Pour installer la prochaine mise à jour (build) du terminal de trading, l'utilisateur décide lui-même de l'installer ou non. En d'autres termes, vous devez lui faire connaître la nouvelle version, mais lui permettre de décider lui-même du moment où il pourra l'installer. Les développeurs d'applications doivent alors disposer de deux versions du terminal installé. Une version avec la construction précédente, et une seconde version avec la dernière construction. Si aucun bogue n'est trouvé dans la nouvelle version lors de l'utilisation du produit, le vendeur indique dans le marché que le produit est compatible avec la dernière version. Si le produit commence à présenter des bogues dans la dernière version, le marquage ne sera pas apposé et l'utilisateur saura qu'il est trop tôt pour installer la nouvelle version.
C'est une option. Plus de choses à penser...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
En fait, cette question se pose depuis longtemps.
Que doivent faire les trois parties maintenant ?
Deux. Le programmeur n'a rien à voir avec cela. L'acheteur doit simplement être en mesure de télécharger le nouveau marché ex. Sans courriels, demandes, captchas, messages de confirmation, etc.
Bien sûr, uniquement sur le matériel, où il est déjà en place.
Les produits sont dotés d'une fonction interne de gestion des versions, que vous pouvez découvrir dans l'article https://www.mql5.com/ru/articles/385.
Lorsqu'une nouvelle version est publiée, un message automatique vous invite à mettre à jour le logiciel. C'est un bon moyen de mettre à jour des versions mineures comme la 2.xx.
Lors de la sortie de versions majeures, vous devrez enregistrer le nouveau produit pour pouvoir le revendre ou continuer à sortir de nouvelles versions sous l'ancien enregistrement avec une mise à niveau gratuite automatique pour les clients existants.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
Les produits disposent d'une version interne, vous pouvez en prendre connaissance dans l'article https://www.mql5.com/ru/articles/385.
Lorsqu'une nouvelle version est publiée, un message automatique vous invite à mettre à jour le logiciel. C'est un bon moyen de mettre à jour des versions mineures comme la 2.xx.
Lorsque des versions majeures seront publiées, vous devrez enregistrer le nouveau produit pour pouvoir le revendre ou continuer à publier de nouvelles versions sous l'ancien enregistrement avec une mise à niveau gratuite automatique pour les clients existants.
Oui, c'est ce qui s'applique aux nouvelles versions des produits.
Mais c'est un peu différent de la question posée dans le fil de discussion.
Qu'en est-il si la nouvelle construction du terminal bloque le fonctionnement normal du logiciel ?
Si vous y réfléchissez, les mises à jour sortent environ deux fois par mois. Il s'avère qu'en mettant à jour le terminal, le client ne pourra plus utiliser le produit pendant quelques semaines. C'est de cela qu'il s'agit.
En plus de cela, le programmeur devrait quitter son emploi actuel et s'occuper à attraper le bug. Et s'il a plusieurs produits sur le marché ?
Donc, ils ont tous des ennuis.
Mais quelle est la solution ?
mais quelle pourrait être la solution ?
il n'y a pas de solution.
Jusqu'à la sortie d'une nouvelle version avec un correctif, le produit restera inactif (ou perdra de l'argent pour le client, ou peut-être même fera-t-il des bénéfices - qui sait ? - puis, une fois le bug du terminal corrigé, une foule d'utilisateurs exigera avec indignation le retour du bug dans le terminal...).
Si aucun bogue n'est détecté dans la nouvelle version lors de l'utilisation du produit, le vendeur marquera le produit sur la Place de marché comme étant compatible avec la dernière version. Si le produit commence à "dysfonctionner" avec la dernière version, aucun marquage n'est effectué et l'utilisateur sait qu'il est trop tôt pour installer la nouvelle version.
Le fournisseur est donc également responsable de la détection des bogues dans les nouvelles versions ? En fait, le produit est utilisé par l'acheteur (et détecte un bug), le problème survient par la faute de MQ (dans le cadre du sujet énoncé), et le vendeur doit prendre le blâme ?
...
C'est une option. Plus de choses à penser...
Idéalement, nous voyons la solution suivante (la question est de savoir si elle est réalisable) :
1- Désactiver l'option d'installation automatique des mises à jour dans le terminal, uniquement le message de disponibilité et la décision de l'utilisateur (ceci a déjà été suggéré quelque part) ;
2- Fonction "rollback to build #..." dans le terminal.
Ensuite, en cas de problème d'EA causé par un problème de nouvelle construction, des mesures temporaires peuvent facilement être prises jusqu'à ce que la situation de construction soit résolue. Les personnes particulièrement prudentes peuvent, à titre de précaution supplémentaire, installer les mises à jour pendant un jour de congé et exécuter leur EA dans le testeur. En fonction de l'adéquation ou de l'inadéquation de l'historique par rapport à la construction précédente, prenez la décision finale de mettre à jour ou d'annuler.
Lorsque vous développez (vendez) un conseiller expert, vous devez spécifier le modèle sur lequel ses performances ont été testées.
Idéalement, nous envisageons la solution suivante (la question est de savoir si elle est réaliste) :
1- Désactiver l'option d'installation automatique des mises à jour dans le terminal, en ne signalant que la disponibilité et en laissant la décision à l'utilisateur (ceci a déjà été suggéré quelque part) ;
2- Fonction "rollback to build #..." dans le terminal.
Ensuite, en cas de problème d'EA causé par un problème de nouvelle construction, des mesures temporaires peuvent facilement être prises jusqu'à ce que la situation de construction soit résolue. Les personnes particulièrement prudentes peuvent, à titre de précaution supplémentaire, installer les mises à jour pendant un jour de congé et exécuter leur EA dans le testeur. En fonction de l'adéquation ou de l'inadéquation de l'historique par rapport à la construction précédente, prenez la décision finale de mettre à jour ou d'annuler.
Lorsque vous développez (vendez) un conseiller expert, vous devez spécifier le modèle sur lequel ses performances ont été testées.
oui, cela me semble être une suggestion raisonnable aussi, (comme une suggestion similaire que tol64 a suggéré immédiatement).
L'installation d'une construction à la demande est la solution logique. Protégera le vendeur et l'acheteur des promoteurs. :)
Le vendeur pourra tester plus tranquillement le produit sur la nouvelle version et exposer les modifications et la nouvelle version, si nécessaire.
Je demande aux développeurs de la plate-forme de réfléchir à ce sujet et à cette proposition en particulier.
L'entreprise a peut-être sa propre vision du problème et de sa solution ?
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
En fait, cette question se pose depuis longtemps.
La situation est la suivante, tout à fait réelle.Le programmeur et le contrôle de la place de marché, après avoir testé le logiciel, le mettent sur la place de marché.
Bien entendu, l'aspect le plus stressant de cette situation est que la réputation du programmeur souffrira davantage que celle de l'entreprise. Parce que les problèmes de la construction doivent encore être identifiés et prouvés.Le client, après avoir payé une certaine somme, découvre quelque temps plus tard que le produit ne fonctionne plus dans la nouvelle construction.
OK. Le programmeur vérifie et constate que le problème se trouve dans la nouvelle version, mais il n'y a aucun moyen de trouver et de localiser le bogue.
Que font les trois partis maintenant ?
Rendre à l'acheteur les fonds qui ont peut-être déjà été investis dans le nouveau développement ?
Envoyer l'acheteur aux développeurs du terminal en disant que le problème se trouve dans le build et que ce n'est pas la faute du programmeur ?
Ou d'une autre manière ?
Le produit recevra beaucoup de réactions négatives pendant cette période et il faudra peut-être le retirer du rayon.
Il s'avère donc que les programmeurs MQL sont dépendants des développeurs de la plateforme. Et ils sont si dépendants que le moindre faux pas peut ruiner leur réputation à la base, ou perturber les commandes futures ou d'autres plans.
D'une manière générale, quelle issue à cette situation est prévue et comment l'entreprise peut-elle la résoudre ?
ZS. Jusqu'à présent, la bonne nouvelle est que l'entreprise développe et organise et soutient elle-même le marché et la vente des produits MQL5. Il y aura donc une lutte pour la qualité, mais qui la paiera de sa réputation et de son argent ?