我对软件的缺陷的看法

你读过RTI国际的新闻稿没有？该篇稿件详细阐述了它为（美国）国家标准技术研究所（National Institute of Standards and Technology，NIST）所进行的研究的结果。这项研究的目标是量化软件缺陷对美国经济所造成的冲击。（要查看这份报告的细节，请访问RTI的网站。

这份新闻稿包含了多个IT行业杂志里相当多的媒体聚焦文章。这些文章中有很多都评论了当前软件开发的过程，它们都主张在软件开发更早的阶段，就利用明确的缺陷追踪和报告系统来进行改良过的软件测试，这样就能够消除掉最终产品的大量缺陷。这些文章中的大多数都支持基础模型的改变，即，将产品保证（QA）和通信计划作为整个开发项目的一个正式部分。

而我对此的评论就是我说了11年的话：“切（表示犹豫、不快或轻蔑等）”！很坦白地说，如果你的机构没有着手解决QA的问题，那么你就需要前进一步。作为应用程序开发的主管，衡量你的成功以及你应用程序的成功的一个标准就是软件缺陷的减少。虽然真正的零缺陷会是可欲而不求的万能药，但是以在开发早期就识别和解决软件缺陷为目标的改良过程是很重要的。

软件缺陷不仅仅会对费用造成直接的冲击，而且会影响到最终用户的选择。在NIST研究报告的概要中，大量的数据都来自软件的最终用户。尽管这都从用户的角度来说的，但是这样的数据会误导读者。

在一般情况下，用户会以两种方式来看待应用程序的功能：它要么好好工作，要么不能工作。他们常常不管或者不懂应用程序可能没有任何问题；而仅仅是由于日常的数据库备份而无法使用。但是，在他们的眼里，应用程序就是崩溃了。如果系统因为离线的关系而无法完成软件的升级，那就是坏了。如果安全系统拒绝他们的访问，他们就认为它坏了。

我们不能说用户有错。最终用户也有他们自己的任务要完成。如果他们所需要用来完成任务的应用程序无法使用了（不论什么原因），你能够想到所带来的经济和文化冲击。此外，不断地发生这样的软件“罢工”会导致你机构里的政治问题。毕竟，各机构花费了大量的金钱来创建或者取得这些软件系统。商业单位的领导者非常了解这类机构的IT费用，并会要求获得其投资的回报。

那你应该做什么来改善这种情况呢？下面的列表提示了一些你本应该已经采取了的措施：

• 在你的开发项目里涵盖进明确的软件QA策划。
• 实现企业范围的缺陷追踪应用程序，这就让最终用户能够报告问题和自行决定工作的重点。
• 建立一个正式的问题通知机制和处理过程（escalation process）。
• 将所有的日常的检修停工计划安排到高峰期之外。
• 明确地列出并交流已知的问题。例如，在真正进行系统更新之前发布一条系统因升级而无法使用的信息。
• 以外行人的语言习惯来提供错误信息，而不是使用生涩难懂的系统信息。

最后，与你的客户进行交流。很多应用程序开发主管没有实现这些紧迫的提议，而这些是可以通过同你的商业伙伴进行面对面的交流实现的。走出你的办公室，去访问你的商业用户，理解应用程序停摆对你客户工作所造成的影响。

---

作者 Scott Withrow具有超过18年以上的IT工作经验，包括IT管理、Web开发管理，以及内部咨询应用程序分析。

---

责任编辑：炒饭

欢迎评论或投稿