当报告的软件问题不是真正的软件问题

Question

道歉，如果这已经被覆盖，或者您认为它确实属于维基。

我是一家为生物科学行业生产微阵列印刷机的公司的软件开发人员。我主要通过C ++中的GUI开发与各种硬件（气动，液压，步进电机，传感器等）连接，以便将样品吸移并打印到微阵列载玻片上。

在加入公司时，我注意到每当出现与硬件相关的问题时，这都会导致整个设置冻结，没有人知道具体问题是什么 - 硬件/软件/误用等等。从那时起我通过引入软件超时和异常处理来更好地识别和处理任何与硬件相关的问题，例如PLC命令未成功完成，不适当的FPGA响应命令以及各种其他死锁类型条件等，从而有所改进。此外，软件现在将记录特定问题的摘要，通知用户并正常退出线程。该软件未嵌入，只使用串行端口连接。

尽管取得了哪些成就，非软件人员仍然不完全明白，在这些情况下，他们向我报告的“软件”问题实际上不是软件问题，而是软件报告问题，但不是造成它。不要误会我的意思，没有什么比享受像大量积木一样的软件错误，以及以任何方式提高稳健性的方法。我现在知道这个系统已经足够了，我对这些事情几乎有第六感。

无论我试图解释多少次，都没有真正渗透。他们仍然报告软件问题本质上是硬件问题（最终得到修复）。

我想听听其他任何经历过类似指点经验的人以及他们用来处理这些经历的方法。

更新 这里有一些很棒的回答，几乎是从同一张赞美诗中唱出来的：更具描述性。我想在硬件出现故障时识别命令并彻底轰炸是第一阶段，但仍然不够。下一阶段将把那些对外行人毫无意义的PLC命令映射到更具启发性的东西。 “PLC命令M71超时”变为“未能初始化注射器系统。检查是否达到足够的真空”等等......

Answer 1

您可以尝试将错误消息标记为“HARDWARE PROBLEM”。可能会明白你的观点。

Answer 2

也许在将问题报告给用户或日志文件中的条目时，您需要明确表明它是出现故障的硬件：

  

“步进电机无响应”。

不幸的是，因为它是人们看到并与之交互的软件，所以他们认为软件 就是

。

Answer 3

系统中没有非软件问题。软件是老板，老板不能责怪工具的失败。

如果底层硬件出现故障，它应该向用户报告哪个组件出了什么问题。如果没有，则是软件问题。

例如，TCP断开意味着它必须重新连接。如果它是FPGA响应，它应该准确地告诉输入和输出到用户，以及谁应该责备。如果没有，这是一个软件问题。

Answer 4

我同意其他海报，但我想补充另一个观点：可能会更糟。他们可能试图解决几天或几周的硬件问题，然后发现后来，当每个人都在枪口下并且一直疯狂地解决它没有得到修复时，他们正在解决错误的问题，事实上，一个软件问题。算你的祝福吧。如果他们总是把它归类为软件问题，至少你知道它。只有这样你才能解决问题，或者提出额外的问题解决或问题识别代码，并使系统更好一点。

此外，这与所有处理过的软件开发人员几乎完全相同。除了通常是软件与用户之外，不是软件与硬件。在这种情况下，似乎没有已知的解决方案。有很多方法可以解决这个问题，但无法解决问题。因此，不断增长的首字母缩略词列表描述了如何责备用户而不是粗鲁：ID-ten-T错误，PICNIC，PEBKAC等。

Answer 5

“如果您正在做的事情不起作用，请停止这样做并尝试别的事情”

正如其他评论所指出的，它是一种沟通，在较小程度上是一种感知问题。人们会更容易将他们不理解的东西归咎于让自己感觉像受害者。电机可能会发出火花，引发火灾并从某人严重超载的情况下爆炸（每次都警告不要涂抹它） - 但如果该软件停止响应，请猜出导致问题的原因？

因为给你的每个用户一个EE或CS类或10个是完全不可能的，所以回到良好的沟通。其基础是4件事（主要是我的意见），没有特别的顺序 - 你观察到什么，你的感受，你的想法和应该做的事情。因此，有了这个想法，我将通过给出这个回应付诸实践。

当某些底层硬件成为关键问题时，您的用户似乎会责怪软件（观察）。试图向用户解释这一点是不切实际的，浪费时间，这不是他们的工作，他们中的大多数人都不会关心（感觉）。你可能想要尝试的是与工程团队讨论他们正在使用的部件，并研究一般使用软件更好的工作。也许从未考虑过输入的一些限制？ （想）改变硬件或者更好地理解它可能是真正的答案，也可能是针对这些用户的更有针对性的错误和反馈（已完成）。

Answer 6

是谁报告了这些问题？

如果是最终用户，我认为这不是问题。他们只是知道他们想做的事情是行不通的。诊断问题不是用户的责任。他们所知道的只是，“我试图做X，Y应该发生，但Z发生了。”除此之外的一切都是你的问题。

如果硬件人员坚持认为问题存在于软件中并且软件人员坚持认为问题存在于硬件中，那么您需要增强软件以更准确地诊断错误，正如ChrisF和其他人所指出的那样。

如果高层人员指责软件组是由于硬件组负责的问题，而你却厌倦了对其他人的错误负责，那么我理解这一点。同样，作为软件人员，您可以创建更精确的错误消息。如果您可以明确地说“步进电机没有响应”或其他什么，那么您就有“道德权威”来坚持要求某人对步进电机进行诊断。只是说，“我很确定这是一个硬件问题”并不会赢得争论。

Answer 7

面向测试的开发（不一定意味着'测试驱动'）是你想要资源的。

基本上，每个子系统都应该有一套相当全面的单元测试来在集成之前识别问题。每次出现问题时都要测试硬件，这样您就可以确定（或几乎可以肯定）它是硬件问题。这意味着必须按照可以彻底测试的方式设计硬件。

我是我的大学机器人团队的整合主管，这种策略有很多帮助。

希望这有帮助。

Answer 8

首先，确保您的用户更有可能阅读并了解您的错误消息。显示“FPGA命令GS_WIDGIT_FROB返回无效响应0xFF45001C。关闭控制器ID 576D。（错误1Xf）”可能对您有用。但是，用户很可能在没有阅读的情况下点击“Ok”。即使他们确实阅读了它，也告诉他们没有有用的信息。无论哪种方式，你都会接到一个电话。显示“Widgit Frobber需要维护”，但仍然会在某处记录所有重要的细节，并且您可能会收到更少的电话。

其次，你知道这是一个硬件问题所以做点什么！拥有您的软件电子邮件硬件支持，或者解决问题所需的一切。如果用户被迫决定采取什么行动来修复它，你可以打赌他们至少在某些时候会弄错。如果用户看到“Widgit Frobber需要维护。已通知硬件支持（票号＃234）”他们知道他们不需要做任何事情。