我与决策者合作，他们希望在他们的业务中更好地使用技术。我发现一张图片值得一千个单词，在某种形式的系统原型中进行讨论总是很有意义的。我已经使用Visio，UML(某种程度上)，思维导图，流程图和模拟WinForms来启动这些赞助商的愿景，以确保每个人都在同一页面上。我似乎总是在寻找可以用于将业务构想与开发过程联系起来的通用流程，以便我们所有人最终都可以解决"解决问题的功能"。

我正在寻找有关如何进行设计过程的建议或者Cliff注释，以使其适用于可能仅花费一周开发时间但也可以用于包含较大项目的应用程序。

我知道这涉及到UML领域，但是我发现我很难找到适当使用各种图表类型的指南，更不用说帮助业务用户理解图表并与之建立联系了。

我们用什么来捕捉系统/应用程序的愿景，然后呈现给项目的发起者？ (在我们编写一行代码之前)...

解决方案

纸或者白板！

对于孤独的开发者，我建议使用纸张。至少在一开始，最终我们可能要使用UML对其进行形式化，但是我认为这不是必需的。

对于一群(在物理上)一起工作的开发人员，我建议使用白板。这样，每个人都可以看到它，并且每个人都可以改进和做出贡献。同样，我们可能要在此时正式化，但我仍然认为它没有必要

当我第一次开始进行OOP(或者设计算法)时，我会在编码时全神贯注。但是，在完成了一些合理的复杂项目之后，我肯定会发现绘制出系统中不同对象之间的交互的好处。

我自己做项目，所以我使用很多索引卡来设计课程，并使用纸张进行交互。关键是它需要易于更改。我曾与图编辑器Dia一起玩过UML，但是进行更改太困难了。我希望能够进行快速更改，因此我可以找出最有效的方法。

值得一提的是，在设计系统时，TDD和执行" spike" [1]项目也可以提供帮助。

[1]来自C＃中的极限编程历险，第8页：

"Spike" is an Extreme Programming term
  meaning "experiement." We use the word
  because we think of a spike as a
  quick, almost brute-force experiment
  aimed at learning just one thing.
  Think of drving a big nail through a
  board.

摘自概念大片：詹姆斯·L·亚当斯(James L. Adams)的《更好的创意指南》：

Intellectual blocks result in an
  inefficient choice of mental tactics
  or a shortage of intellectual
  ammunition. . . . 1. Solving the
  problem using an incorrect language
  (verbal, mathematical, visual) -- as
  in trying to solve a problem
  mathematically when it can more easily
  be accomplished visually

(第71页，第3版)

不用说，如果我们选择使用图表来捕捉可以用数学更好地捕捉的思想，那同样是不好的。当然，技巧是找到正确的语言来表达问题和解决方案。当然，使用一种以上的语言来表达问题和解决方案可能是适当的。

我的观点是，我们假设图表是最佳的选择。我不确定我是否愿意做这个假设。通过框架要求和建议的设计的其他方法，我们可能会得到更好的答案(客户可能会对结果感到满意)。

顺便提一下，强烈建议我们阅读概念性大片。

阅读Kruchten的4 + 1视图。

这是我们可以继续进行的方法。

• 将用例收集到用例图中。这将显示参与者和用例。该图并不是从很多细节开始的。
• 优先考虑用例，以专注于高价值的用例。
• 写叙事。如果需要，可以绘制活动图。

以上是完全非技术性的。 UML对要使用的形状施加了一些规则，但是除此之外，我们可以使用最终用户术语来描述事物。

• 我们可以进行名词分析，绘制类图以说明实体和关系。首先，这些将是用户术语。没有令人讨厌的技术含量。
• 我们可以展开活动图或者添加序列图以显示处理模型。这将从最终用户对处理的非技术描述开始。
• 我们可以遍历类和活动图，以从分析过渡到设计。在某些时候，我们将脱离分析而进入工程模式。用户可能不想看到所有这些图片。
• 我们可以为开发视图绘制组件图，为物理视图绘制部署图。随着我们对系统概念的扩展和完善，这些操作也会反复进行。

在设计应用程序时(我主要创建Web应用程序，但这确实适用于其他应用程序)，我通常会创建用户案例来确定最终用户的真正需求。这些构成了典型的"业务需求"。

在确定用户故事之后，我创建流程图以列出人们使用该应用程序时要走的路。

在该步骤(有时需要批准过程)之后，我创建界面草图(笔/铅笔和方格纸)，然后开始数据库的布局。此步骤以及下一步通常是最耗时的过程。

下一步是获取草图并将其变成清理后的线框。我将OmniGraffle用于此步骤-比Visio提前数年。

在这之后，我们可能想要进行典型的UML图或者其他对象布局/功能组织，但是业务人员并不需要那么在意这种细节：)

当我整理设计时，我关心的是将思想清晰，轻松地传达给观众。该受众由(通常)具有不同背景的不同人群组成。我不想做的是进入特定设计模型的"教学模式"。如果我必须花大量时间告诉客户带有实心箭头的箭头的含义，以及它与空心箭头或者方形与圆形的区别，那么我没有取得进展，至少没有取得进展想要。

如果它是非正式的，我将在白板或者某些纸块上以及最多简单的箭头上画出草图。此时，粗略设计的目的是确保我们在同一页面上。虽然会因客户而异。

如果它更正式，我可能会抽出UML工具并整理一些图表，但大多数情况下，我的客户不编写软件，并且可能对内部人员只是一点点兴趣。我们将其保持在"泡泡和线条"级别，并可能在需要澄清的地方列出一些项目符号列表。我的客户通常不希望看到类图或者类似的图。

如果需要显示一些GUI交互，我将在Visual Studio中将一些简单的窗口原型放在一起，这是快速而简单的。我发现客户可以很轻松地与之建立联系。

简而言之，我制作了一些简单的图纸(以某种格式)，可以将设计传达给感兴趣的各方和利益相关者。我确保我知道我想要它做什么，更重要的是，他们需要它做什么，并与之交谈。它通常不会进入杂草，因为人们在那里迷路了，我发现花时间将所有事物绘制到第n级并不花时间。最终，如果客户和我(以及所有其他有关方面)在讨论完设计之后都在同一页上，那么我就是一个快乐的人。

对于小的任务或者非常有限的任务，我认为开发人员几乎都同意，任何形式的图表都是不必要的步骤。

但是，在处理更大，更复杂的系统时，尤其是当两个或者多个流程必须交互或者需要复杂的业务逻辑时，流程活动图可能非常有用。我们在开发中使用了相当纯净的敏捷方法，发现这些几乎是我们使用的唯一图类型。令人惊讶的是，仅通过将前面的所有大块部件与流水线连接起来，我们就可以优化高层设计。我不能特别强调针对问题定制图表的重要性，而不是相反，因此尽管链接提供了一个很好的起点，但只需添加有意义的内容来表示系统/问题。

在存储方面，白板非常适合集思广益，并且当想法还在不断完善时，但是我认为一旦想法最终形成，电子和Wiki会更好(如果我们幸运的是能够在工作中使用Mac ：)。对于所有新手来说，拥有一个可以转储所有这些图的区域可能非常有帮助，他们可以快速掌握整个系统，而不必深入研究代码。同样，由于活动图表示较大的逻辑块，因此不必始终保持最新状态。是的，当我们对系统进行大的更改时，可以，但是希望仍然可以使用现有的图表来计划更改。

如果我们正在与众多利益相关者和众多贡献者一起从事大型且规避风险的项目，那么UML建议非常有效。即使在这些项目中，开发原型向决策者展示也确实有帮助。通常，通过UI和典型的用户故事就足够了。就是说，我们必须提防针对决策者的用户界面会倾向于使他们忽略一些重要的后端问题，例如验证，业务规则和数据完整性。他们倾向于将这些问题注销为"技术"问题，而不是业务决策。

另一方面，如果我们正在开发一个敏捷项目，在该项目中可以快速进行代码更改(并快速回滚错误)，那么我们也许可以制作出所有工作的演化原型。应用程序架构应足够灵活且足够灵活以支持快速更改(例如裸对象设计模式或者Rails风格的MVC)。它有助于形成鼓励实验的开发文化，并承认BDUF不能预测成功软件的运行情况。

我是一个敏捷的人，所以我倾向于不花很多时间在图表上。当然，有时候在白板或者餐巾纸上画草图会有助于确保我们了解特定的问题或者要求，但是在客户面前展示可运行的软件以使他们能够看到其工作原理并不能真正胜过。如果客户会在前期设计中接受频繁的迭代和演示，那么我就坚持下去。如果他们可以通过单元测试或者集成测试的形式早日获得反馈，那就更好了(Fit这样的方法在这里效果很好)。

我通常不喜欢原型，因为原型经常成为最终产品。我很不幸地在一个项目上工作，该项目基本上是在扩展商业产品，后来证明是打包销售的"概念证明"。在针对核心应用程序记录了1000多个缺陷之后，该项目被取消(不包括我们当前正在进行的任何增强或者自定义)。

我尝试使用UML，发现除非看图的人理解UML，否则它们几乎没有帮助。屏幕模型通常不是一个坏主意，但它们只显示直接影响用户的应用程序一侧，因此，对于任何不呈现的内容，我们不会有太多的收获。奇怪的是，像Visual Studio中的工作流设计器这样的工具会产生非常清晰的图表，非开发人员很容易理解，因此，如果应用程序足够复杂，可以从中受益，那么它就成为生成核心应用程序工作流的好工具。

尽管如此，在这些年来我使用的所有方法中，没有什么能让用户动手做一些事情来让我们知道我们对问题的理解程度。

我建议阅读Joel的有关"无痛功能规范"的文章。第1部分的标题为"为什么要打扰？"。

我们在工作中使用样机屏幕("快速简便的屏幕原型")。更改屏幕很容易，并且scetches清楚地表明这只是设计而已。

然后将样机包含在包含规范的Word文档中。