user-interface - UI 驱动开发

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 提供事实和引用来回答它.

5年前关闭。




Improve this question




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

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

你们有什么感想？

Answer 1

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

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

典型的周期是:

起草一些需求和用例，范围非常有限，非常集中。

创建一个测试协议(protocol)，使我们能够收集有关此功能的数据(可用性、易用性、接受度、性能等)。

创建或扩展应用程序以包含此功能

让一些用户使用可用性测试的敏捷调整来测试应用程序(参见 Ruben's Handbook of Usability Testing)，我们将测试 session 限制为 15 分钟，并进行 15 分钟的 debreifing。

从测试中提取有用的数据以注入(inject) future 的迭代。

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

这种工作方式迫使我们在软件开发生命周期的早期就为客户提供 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/