excuses si cela a déjà été couvert ou que vous pensez que cela appartient vraiment au wiki.
Je suis un développeur de logiciels dans une entreprise qui fabrique des machines d'impression MicroArray pour l'industrie des biosciences. Je suis principalement impliqué dans l'interface avec divers morceaux de matériel (pneumatique, hydraulique, moteurs à pas, capteurs, etc.) via le développement de l'interface graphique en C ++ pour aspirer et imprimer des échantillons sur des diapositives à micropuce.
En rejoignant la société, j'ai remarqué que chaque fois qu'il y avait un problème lié au matériel, cela ferait geler l'ensemble de la configuration, sans que personne ne soit plus sage quant à ce que le problème spécifique était - matériel / logiciel / mauvaise utilisation, etc. depuis lors J'ai quelque peu amélioré les choses en introduisant des délais d'expression logiciels et de manipuler des exceptions pour mieux identifier et traiter les problèmes liés au matériel que surgir, par exemple, les commandes d'API ne sont pas complétées avec succès, des commandes de réponse FPGA inappropriées et diverses conditions de type impasse, etc. En outre, le logiciel Je vais maintenant enregistrer un résumé du problème spécifique, informera l'utilisateur et quitter le fil gracieusement. Ce logiciel n'est pas intégré, il suffit d'interfacer à l'aide de ports série.
Malgré ce qui a été atteint, les gars non logiciels n'apprécient toujours pas que dans ces cas, le problème "logiciel" qu'ils rapportaient ne me rapportent pas vraiment un problème logiciel, plutôt que le logiciel signalant un problème, mais ne pas le causer. Ne me trompez pas, il n'y a rien que je profite de plus que de descendre sur des bugs logiciels comme une tonne de briques et de regarder des moyens d'améliorer la robustesse de quelque manière que ce soit. Je connais le système assez bien maintenant que j'ai presque un sixième sens pour ces choses.
Peu importe combien de fois j'essaie d'expliquer cela, rien ne pénètre vraiment pénètre. Ils rapportent toujours ce que sont essentiellement des problèmes matériels (qui finissent par être réparés) comme des logiciels.
J'aimerais entendre des autres qui ont subi des expériences de pointage similaires et quelles méthodes utilisées pour les traiter.
8 Réponses :
Vous pouvez essayer d'étiqueter les messages d'erreur comme "problème matériel". Pourrait avoir votre point sur le point.
Simple, basique et brillant. Joli!
Mais soyez prudent - vous ne voulez bien sûr pas pré-étiqueter chaque erreur en tant que problème matériel. Ensuite, vous perdrez de la crédibilité. Je ne pense pas que Joeri le suggère, mais je voulais dire que c'est clair.
Oui, juste commentaire. C'est juste que dans certaines situations telles que lorsqu'un axe ne parvient pas à atteindre son poste zéro, cela a toujours été dû à un défaut de la phase d'étalonnage du matériel. Si cela n'est pas configuré à droite, le logiciel échouera toujours. De mes observations, ses mêmes 5 ou 6 problèmes spécifiques se reproduisent à plusieurs reprises, ce qui pourrait être limité à ces instances.
Je ne voulais pas tout balayer sous le tapis du problème du matériel. Je viens d'avoir des problèmes dans le passé avec des erreurs qui étaient vraiment dues à des bases de données externes qui sont configurées de manière incorrecte et je n'ai résolu que le flux de plaintes sans fin en relâchant l'erreur comme "erreur de base de données". En cas de doute, vous pouvez l'appeler "erreur inconnue, défaillance d'étalonnage du matériel présumé"
Il n'y a pas de problème non logiciel dans un système. Le logiciel est le patron et le patron ne peut pas blâmer l'échec des outils.
Si le matériel sous-jacent est dysfonctionnement, il devrait signaler à l'utilisateur ce qui s'est mal passé avec quel composant. Si ce n'est pas le cas, c'est un problème logiciel.
Par exemple, la déconnexion TCP signifie qu'il doit se reconnecter. Si c'est une réponse FPGA, il devrait dire exactement quelles étaient les entrées et les sorties
Je suis d'accord! Mais cela pour laquelle j'ai eu le système de signaler quelle commande spécifique PLC / FPGA a des problèmes avec ...
Peut-être pour signaler le problème sous forme de message à l'utilisateur ou à une entrée dans le fichier journal, vous devez le faire expliquer explicitement que c'est le matériel qui est en défaut:
"moteur pas à pas répondant".
Malheureusement, parce que c'est le logiciel que les gens voient et interagissent avec ils supposent que le logiciel est tout ce qu'il y a.
Je suis d'accord avec les autres affiches, mais je voulais ajouter une autre perspective: cela pourrait être pire. Ils pourraient essayer de résoudre les problèmes matériels pendant des jours ou des semaines, puis découvrez plus tard, lorsque tout le monde est sous le pistolet et qu'il y a été fou de ne pas être réparé, qu'ils abordaient le mauvais problème et c'était en fait , un problème logiciel. Alors comptez vos bénédictions. S'ils le classent toujours comme un problème de logiciel, au moins vous le savez. Ce n'est qu'alors que pouvez-vous dépanner, peut-être mettre en place une résolution de problèmes supplémentaire ou un code d'identification de problèmes et rendre le système un peu mieux.
En outre, cela est à peu près la même chose que chaque développeur de logiciels partout jamais confronté. Sauf généralement, c'est le logiciel par rapport à l'utilisateur, pas le logiciel par rapport au matériel. Et dans ce cas, il semble qu'il n'y a pas de solution connue. Beaucoup de façons de résoudre le problème, mais aucun moyen de le réparer. Ainsi, la liste toujours croissante des acronymes décrivant comment blâmer l'utilisateur sans être impoli: ID-TEN-T d'erreur, pique-nique, Pebkac, etc.
Développement axé sur les tests (non nécessaire signifie "Test-Driven") est de savoir que vous devriez les ressources nécessaires.
Fondamentalement, chaque sous-systèmes devrait avoir un ensemble de tests unitaires raisonnablement approfondi pour identifier le problème avant l'intégration. Chaque fois qu'un problème se produit, testez le matériel afin que vous puissiez savoir à coup sûr (ou presque sûr) que c'est le problème matériel. Cela signifie que le matériel doit être conçu de la manière dont il peut être minutieusement testé.
J'étais une tête d'intégration pour l'équipe de robot collégial et cette tactique aide beaucoup.
J'espère que cela aide.
Je ne pense pas que ce problème est le problème de la discussion. On dirait que vous abordez des problèmes survenus dans le développement et OP discutait des problèmes dans la production. Donc, même si les tests fonctionnent et que le code était correct, il peut toujours y avoir une défaillance dans le monde réel.
"Si ce que vous faites ne fonctionne pas, arrêtez de le faire et essayez quelque chose d'autre"
Comme indiqué dans d'autres commentaires, c'est une communication et dans une moindre mesure, problème de perception. Les gens vont blâmer ce qu'ils ne comprennent pas beaucoup plus facilement de se faire sentir comme une victime. Un moteur pourrait être étincelant, jeter le feu et exploser de quelqu'un de surcharge grossièrement un chargeur (avec chaque avertissement à ne pas placez tout dessus) - mais si ce logiciel cesse de répondre, devinez ce qui a causé le problème?
Puisque chacun de vos utilisateurs, une classe EE et CS ou 10 est complètement hors de question, retombez sur une bonne communication OLE. La base est de 4 choses (surtout mon opinion) sans ordre particulier - ce que vous observez, de ce que vous ressentez, de ce que vous pensez et de ce qui devrait être fait. Donc, avec cette idée, je vais mettre en pratique en donnant cette réponse.
Il semble que vos utilisateurs aiment blâmer le logiciel lorsque certains du matériel sous-jacent sont le problème clé (observer). Essayer d'expliquer cela avec les utilisateurs à ce sujet n'est pas impraticable et une perte de temps, ce n'est pas leur travail et la plupart d'entre eux ne s'en soucieront pas. Ce que vous voulez essayer, c'est parler avec l'équipe d'ingénierie des pièces qu'ils utilisent et examinent les choses qui fonctionnent mieux avec le logiciel en général. Peut-être que les intrants n'ont jamais été pris en compte? (Pensez) modifier le matériel ou simplement une meilleure compréhension de cela pourrait être la vraie réponse ainsi que des erreurs plus ciblées et des commentaires sur ces utilisateurs (faites).
Qui est-ce qui signale les problèmes?
Si ce sont les utilisateurs finaux, je pense que c'est un non-problème. Ils savent simplement que ce qu'ils essaient de faire ne fonctionne pas. Ce n'est pas la responsabilité de l'utilisateur de diagnostiquer le problème. Tout ce qu'ils savent, c'est: "J'ai essayé de faire x, y aurait dû arriver, mais plutôt z est arrivé." Tout au-delà de cela est votre problème.
Si les personnes matérielles insistent sur le fait que le problème est dans le logiciel et que les logiciels insistent sur le fait que le problème est dans le matériel, vous devez améliorer le logiciel pour diagnostiquer des erreurs plus précisément, comme l'a noté Chrisf et d'autres.
Si les plus hautes augmentent le groupe de logiciels pour des problèmes liés à la responsabilité du groupe de matériel et vous êtes malade de prendre le blâme pour les erreurs d'autres personnes, d'accord, je comprends cela. Encore une fois, comme le gars logiciel, vous avez le pouvoir de créer des messages d'erreur plus précis. Si vous pouvez explicitement dire, "Stepper Motor ne répond pas" ou autre chose, alors vous avez "l'autorité morale" d'insister sur le fait que quelqu'un exécute des diagnostics sur le moteur pas à pas. Je viens de dire: "Je suis sûr que c'est un problème matériel" ne va pas gagner un argument.
Tout d'abord, assurez-vous que vos utilisateurs sont plus susceptibles de lire et Deuxièmement, vous savez que c'est un problème matériel, donc
"Ce que nous avons ici, c'est un problème de communication."
@CRAIG MCQUEN: Je pense que la phrase est "... l'incapacité de communiquer".
Selon IMDB, la citation correcte (de Cool Hand Luke ) est la suivante: "Qu'est-ce que nous avons ici est [a] défaut de communiquer." Je devais mettre le "a" là-bas, alors je ne suis pas sûr de faire confiance à IMDB.
@Musigenèse: Je ne pense pas que le "A" appartient. Mais je pourrais avoir tort. Cela fait quelques années que je l'ai vu.
WOW, IMDB avait raison: YouTube.com/watch?v=Sno9JYZ82P&feature=Related Peut-être que c'est pourquoi Neal Armstrong a laissé tomber le "A" dans son discours de la lune - c'était une chose de 60 ans.
@Dandan: Ou peut-être "C-MmMyoon-Cate"
@Musigenesis: IMDB avait raison et j'avais aussi raison. (Pats auto sur le dos)
La chose pire que ceci est lorsque le matériel de quincaillerie convainc le patron aux cheveux pointilleux qui est vraiment un problème de logiciel. Et même après avoir démontré de différentes manières qu'un enfant de 6 ans puisse comprendre que le logiciel n'est pas en faute, le matériel matériel obtient les louanges et les lève et le gars logiciel (c'est-à-dire «vous", ce qui signifie "moi") continue d'être la chèvre. Solution? Trouvez un autre patron, apparemment.
La solution consiste à réécrire le logiciel de sorte qu'elle ne se bloque jamais, mais si elle est assise là et dit "Le matériel joue" Le matériel joue stupide b gg rs ", de préférence avec une folie d'informations de diagnostic et tout en ayant toujours tout le reste fonctionner correctement. Si ce n'est pas possible de faire cela, vous faites quelque chose de vraiment faux.