UI驱动开发

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

此需求收集方法似乎也自动传达了数据和关联行为.

你们有什么感想？

实际上在这方面确实有意义.用例的不同之处在于它们不能以相同的方式使用.用例将有助于提取和形式化需求.

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

典型的周期是:

起草了一些要求和用例,范围非常有限,非常集中.

创建一个测试协议,允许我们收集有关此功能的数据(可用性,易用性,接受性,性能等).

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

有一些用户使用敏捷适应性测试来测试应用程序(参见Ruben的可用性测试手册),我们将测试会话限制为15分钟,并且15分钟的重复性.

从测试中提取有用的数据,以便在将来的迭代中注入.

当用户要么不确切地知道他们想要什么或者不能告诉我们什么时,这种方法是非常有用的.因此,我们必须设计测试,以便收集关于软件实际有用性的客观数据给用户,并尝试调整下一次迭代.(如果我打电话给他们的话,我们的许多"顾客"都很残疾,不能说话,所以我们必须要有创意).

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

虽然我们主要针对非常具体的情况开发了这种技术,但我们在正常软件上对普通用户进行了一些测试并得到了非常积极的结果.设计将很快收敛到usre的需求.此外,他们参与这种设计方法的事实对目标社区对产品的接受也产生了非常积极的影响.

不幸的是,在我们发布我们的结果并扩展这一研究线之前,内部的strifes让实验室解体了,真是太遗憾了.

所以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/