6

UI 驱动开发的想法是否有意义？我们的大多数客户都喜欢以屏幕的形式表达他们的要求。例如，我想要一个屏幕来做这个和那个。有时他们甚至会自己决定屏幕的布局（这可能是因为今天的客户已经在他们的大部分任务中使用了软件应用程序）。

此外，这种需求收集方法似乎可以自动传达数据和相关行为。

你们有什么感想？

4

5 回答 5

6

实际上，在这方面它是有道理的。用例在这里的不同之处在于它们不能以相同的方式使用。用例将有助于提取和形式化需求。

不久前我在一个 UI 实验室工作，我们玩弄了这个概念，尽管我们没有这样称呼它。这里的基本思想是我们将使用敏捷迭代方法进行开发，我们将使用可用性测试来帮助收敛到所需的解决方案。

典型的周期是：

  • 起草一些需求和用例，范围非常有限，非常集中。
  • 创建一个测试协议，使我们能够收集有关此功能的数据（可用性、易用性、接受度、性能等）。
  • 创建或扩展应用程序以包含此功能
  • 让一些用户使用可用性测试的敏捷调整来测试应用程序（请参阅Ruben 的可用性测试手册），我们将测试会话限制为 15 分钟，并进行 15 分钟的 debreifing。
  • 从测试中提取有用的数据以注入未来的迭代。

当用户要么不确切知道他们想要什么或不能告诉我们时，这种方法特别有用。因此，我们必须设计测试来收集关于软件对用户的实际有用性的客观数据，并因此尝试调整下一次迭代。（我们的许多“客户”，如果我可以这样称呼他们的话，他们是重度残障人士，不会说话，所以我们必须要有创意）。

这种工作方式迫使我们在软件开发生命周期的早期就为客户提供 GUI，因为它是我们直接测试的中心点，可以说它是 GUI 驱动的设计，因为融合的驱动力是用户与系统的交互。

尽管我们主要针对非常特定的情况开发了这种技术，但我们在普通软件上与普通用户进行了一些测试，并获得了非常积极的结果。设计将很快收敛到用户的需求。他们参与这种设计方法的事实也对目标社区对产品的接受度产生了非常积极的影响。

不幸的是，在我们能够发表我们的结果并扩大这一研究范围之前，内部冲突已经拆除了实验室，真的很遗憾。

因此，UIDD（如果你原谅这个不好的首字母缩写词）将成为 TDD 系列软件开发方法的成员，其中迭代取决于用户交互。

关于该主题的补充阅读：

http://www.codinghorror.com/blog/archives/001091.html

http://cakebaker.42dh.com/2007/07/07/usability-driven-development/

http://www.springerlink.com/content/l413k76812896gnt/

http://www.agilemodeling.com/essays/agileUsability.htm

http://www.uxbooth.com/blog/how-test-driven-development-increases-overall-usability/

于 2009-04-02T09:37:04.790 回答
2

你在做什么开发？当我开发 Web 应用程序（flex 或 php）时，我使用绘图（线框），这样我就可以让客户了解应用程序的流程/外观，而无需编写任何代码。

没有适合每个人的“正确的发展方式”，您只需要找到最适合您的方式。干杯！

于 2009-04-02T09:50:21.950 回答
1

我发现这是收集需求的合理方式。我会小心实际构建屏幕，然后直接开发功能。您会发现代码重用率很低，并且您将拥有一个看起来很漂亮的应用程序，但速度很慢或不能完全正确地工作。它将适用于某些项目，而不适用于其他项目，具体取决于需求的复杂程度以及预测数据瓶颈、缓存问题等问题的能力。

听起来它类似于行为驱动开发、线框图和用户故事。

于 2009-04-02T09:20:50.743 回答
0

我认为您在这里真正谈论的是 用例- 请参阅本文以获取介绍。

于 2009-04-02T09:18:53.523 回答
0

故事测试驱动开发只要你认真对待自动化部分，我认为这是一个很好的主意。如果你不能自动化你的测试，那么你就有麻烦了。在这里查看一篇关于它的论文：http: //www.industriallogic.com/papers/storytest.pdf 这听起来不像您的客户正在为您提供自动化 UI 测试，但我认为这是最好的方法。

于 2009-04-02T09:20:22.850 回答