我公司从详细的规范文档开发了一个丰富的GUI，编写为100多个用例（UC）。这些详细的UC推动了这一发展。它们被编写为包含actor和description列的表。我们（我和其他人）已经破坏了真实的UC散文风格，以支持我们的应用程序的交互性。
我们还使用规范生成（手动）测试规范，因此细节（对我来说）似乎很重要。此测试规范用于验证以获得签名。
注意：我们的产品还有许多组件，而不仅仅是GUI。 GUI团队是6-10强，整个项目，大约60。
直到最近，我才创建了一个“故事板”文档，详细说明了每个面板及其与规范相关的交互。此外，还有一个GUI架构，以及主要子组件的设计。哎哟!它导致了非常缓慢的开发时间，糟糕的代码库（哈！）和缺乏动力的团队。
该应用程序更像是一个IDE，允许用户使用拖放式流程图来创建自己的测试用例（用于移动'电话测试）。它非常复杂，成熟（7年以上）并提供许多功能。然后运行测试用例并分析结果。作为这样一个免费工具（用户可以通过该工具跟踪几乎无限数量的路径），它似乎无意中使用顺序用例。我们使用“O”表示可选，“R”表示可重复，嵌套和许多其他“扩展”。 UC在设计IDE交互方面基本上是不匹配的。将此应用程序视为提供空白工作界面（如文字处理程序或电子表格），用户可以按任何顺序执行任何操作：这导致了UC膨胀。
目前，我们希望简化从100多个UC到基础UC的规范：“开发测试用例”，“运行测试用例”，“分析结果”（或类似的东西）。
虽然我理解我们的UC不是“真正的”UC（专注于商业价值），但我担心，作为GUI和开发人员的团队负责人，如果没有详细信息，我的家伙将不会知道什么到开发。三个UC看起来太抽象了。
我们采用统一流程的形式，预先制定规范。也许我们应该改变一个更敏捷的过程，开发人员自己进行交互设计。
答案 0 :(得分：1)
某种基于拖放的IDE / GUI工具本来不错？具有记录交互的功能，并在动画上添加描述性文本。而不是UC的设计IDE，你让IDE做UC。在IDE / GUI处于特定状态时，您可以让弹出窗口显示写入UC或弹出窗口上的某些文本会发生什么，每次特定状态由用户或开发人员限制时都会出现。弹出窗口可以连接到更多弹出窗口，具体取决于现实世界中发生的事情。就像那些询问“你现在想做什么？”的文字冒险一样。并且UC弹出式kan trigg事件可根据规范制作的测试套件更改IDE / GUI或更改其他状态。
测试套件地图输入到输出。与IDE / GUI选择输入和输出的交互改变了程序数据层原型的状态。从理论上讲，你可以使用输入/输出表（一些信息大）而不是算法来完成所有功能。实际上，当一个表足够大时，让一个程序员使用它作为测试套件来做算法并交换表。该表现在用作测试套件报告错误。
让IDE / GUI工具为最终事件驱动的IDE / GUI生成代码，通过事件与代码，数据和用户层进行交互，或者更好地让它在一个层中反射，以摆脱无穷无尽重组。
那只是一些idéas
答案 1 :(得分：0)
在OpenLaszlo中建议采用四步设计流程： 1.Wire帧。 2.Storyboards。 3.Animations。 4.工程原型。
非常有趣...... alt text http://www.openlaszlo.org/lps4.7/docs/developers/images/design_sec3_ill.jpg
