我经常与希望在他们的业务中更好地使用技术的决策者合作。我发现一张图片胜过一千个单词，并且在某种图表中对系统进行原型设计总是有助于讨论。我已经使用 Visio、UML（有点）、思维导图、流程图和模拟 WinForms 来启动这些赞助商的愿景，以确保每个人都在同一个页面上。我似乎一直在寻找可用于将业务愿景与开发流程结合起来的通用流程，以便我们都以相同的方式结束，“解决问题的功能”。
我正在寻找有关如何处理设计过程的建议或 Cliff 注释，以便它适用于可能只需要一周时间开发的应用程序，但也可以用于包含更大的项目。
我知道这深入到 UML 领域，但我发现我很难找到适当使用各种图表类型的指南，更不用说帮助业务用户理解图表并与它们相关联了。
您使用什么来捕捉系统/应用程序的愿景，然后呈现给项目的发起人？（所有在你写一行代码之前）......
纸或白板！
对于孤独的开发者，我建议使用纸张。至少一开始，最终你可能想用 UML 将它形式化，但我认为没有必要。
对于一组（物理上）一起工作的开发人员，我建议使用白板。这样，每个人都可以看到它，每个人都可以改进和贡献。同样，您可能想在这一点上正式化，但我仍然认为没有必要
当我第一次开始做 OOP（或设计一种算法）时，我会在编码时在脑海中完成这一切。但是在做了一些合理的复杂项目之后，我肯定看到了绘制系统中不同对象之间的交互的好处。
我自己做项目，所以我使用很多索引卡来设计课程和纸来进行互动。关键是它需要易于更改。我曾经使用过图表编辑器 Dia 来进行 UML，但是进行更改太难了。我希望能够进行快速更改，以便找出最有效的方法。
值得一提的是，TDD 和做“spike”[1] 项目也可以在设计系统时提供帮助。
[1] 来自 C# 中的极限编程冒险，第 8 页：
“Spike”是一个极限编程术语，意思是“实验”。我们使用这个词是因为我们认为尖峰是一种快速、几乎是蛮力的实验，目的是只学习一件事。想想用木板钉一个大钉子。
对于小型或非常有限的任务，我认为开发人员几乎普遍同意任何类型的图表都是不必要的步骤。
然而，在处理更大、更复杂的系统时，尤其是当两个或多个流程必须交互或需要复杂的业务逻辑时，流程活动图可能非常有用。我们在开发中使用相当纯粹的敏捷方法，发现这些几乎是我们使用的唯一图表类型。令人惊讶的是，您可以通过将所有大件放在您面前并用流线连接它们来优化高级设计。我不能强调根据您的问题定制图表的重要性，而不是相反，因此虽然链接提供了一个很好的起点，但只需添加有意义的内容来表示您的系统/问题。
至于存储，白板非常适合头脑风暴和想法仍在完善时，但我认为，一旦想法形成相当最终的形状，电子和 wiki 会更好（如果你是，OmniGraffle 是图表之王很幸运能够在工作中使用 Mac :) 。拥有一个可以转储所有这些图表的区域对于新手快速掌握系统的整体部分而无需深入研究代码非常有帮助。此外，由于活动图代表更大的逻辑块，因此不存在必须始终保持最新状态的问题。当您对系统进行重大更改时，可以，但希望无论如何都可能使用现有图表来计划更改。
来自概念大片：更好的想法指南 James L. Adams：
智力障碍导致智力策略选择低效或智力弹药短缺。. . . 1. 使用不正确的语言（口头的、数学的、视觉的）解决问题——比如试图用数学方法解决一个问题，而这个问题可以更容易地在视觉上完成
（第 71 页，第 3 版）
不用说，如果您选择使用图表来捕捉可能用数学更好地捕捉的想法，那同样糟糕。当然，诀窍是找到正确的语言来表达问题和解决方案。当然，使用一种以上的语言来表达问题和解决方案可能是合适的。
我的意思是你假设图表是最好的方法。我不确定我是否愿意做出这样的假设。您可能会通过其他一些制定要求和提议的设计的方法获得更好的答案（并且客户可能对结果更满意）。
顺便说一句，强烈推荐阅读概念性大片。
阅读 Kruchten 的4+1 Views。
这是您可以继续的方法。
将用例收集到用例图中。这将显示参与者和用例。该图并没有从很多细节开始。
优先考虑用例以关注高价值用例。
写叙述。如果需要，您可以绘制活动图。
以上完全是非技术性的。UML 对要使用的形状施加了一些规则，但除此之外，您可以用最终用户术语来描述事物。
您可以进行名词分析，绘制类图来说明实体和关系。首先，这些将在用户术语中。没有令人讨厌的技术内容。
您可以展开活动图或添加序列图以显示处理模型。这将从最终用户对处理的非技术描述开始。
您可以遍历类和活动图以从分析转向设计。在某些时候，您将退出分析并进入工程模式。用户可能不想看到所有这些图片。
您可以为开发视图绘制组件图，为物理视图绘制部署图。这些也将随着您对系统概念的扩展和完善而迭代。
在设计应用程序时（我主要创建 Web 应用程序，但这确实适用于其他应用程序），我通常会创建用户故事来确定最终用户真正需要什么。这些构成了典型的“业务需求”。
在确定用户故事后，我会创建流程图来列出人们在使用应用程序时将采用的路径。
在该步骤之后（有时会获得批准过程），我创建界面草图（钢笔/铅笔和方格纸），并开始数据库的布局。这一步和下一步通常是最耗时的过程。
下一步是绘制草图并将它们变成清理过的线框。我在这一步中使用 OmniGraffle——它比 Visio 早了几光年。
在此之后，您可能想做典型的 UML 图，或其他对象布局/功能组织，但业务人员不会太在意那种细节 :)
当我整合一个设计时，我关心的是如何将想法清晰而轻松地传达给观众。该观众由（通常）具有不同背景的不同人组成。我不想做的是进入特定设计模型的“教学模式”。如果我必须花大量时间告诉我的客户实心箭头的含义以及它与空心箭头的不同之处或方形与圆形的含义，我没有取得进展——至少没有取得进展我想要。
如果它是相当非正式的，我会在白板或一些纸上画出来——最多是块和简单的箭头。此时粗略设计的重点是确保我们在同一页面上。不过会因客户而异。
如果它更正式，我可能会拿出一个 UML 工具并整理一些图表，但大多数我的客户不编写软件，并且可能只是对内部部分感兴趣。我们将其保持在“气泡和线条”级别，并且可能会整理一些需要澄清的项目符号列表。我的客户通常不想看到类图或类似的东西。
如果我们需要展示一些 GUI 交互，我会在 Visual Studio 中拼凑一些简单的窗口原型——它既快速又简单。我发现客户可以很容易地理解这一点。
简而言之，我制作了简单的图纸（以某种格式），可以将设计传达给相关方和利益相关者。我确保我知道我想要它做什么，更重要的是——他们需要它做什么，并与之交谈。它通常不会进入杂草，因为人们迷路了，而且我发现没有时间花时间将所有内容绘制到第 n 级。最终，如果客户和我（以及所有其他相关方）在讨论完设计后在同一页面上，我是一个快乐的人。
我是一个敏捷的人，所以我倾向于不花很多时间在图表上。有时候，在白板或餐巾纸上画草图有助于确保您了解特定问题或要求，但没有什么比将工作软件放在客户面前让他们了解它是如何工作的更好的了。如果您的客户会接受频繁的迭代和演示而不是前期设计，我建议您去接受它。如果他们能够以通过单元或集成测试的形式获得早期反馈，那就更好了（Fit之类的东西在这里很好用）。
我通常不喜欢原型，因为原型往往成为最终产品。我不幸地从事一个项目，该项目基本上是扩展商业产品，结果证明是一个“概念证明”，被打包并出售。在针对核心应用程序记录了 1000 多个缺陷后，该项目被取消（不包括我们目前正在进行的任何增强或定制）。
我尝试过使用 UML，发现除非看图表的人理解 UML，否则它们几乎没有帮助。屏幕模型通常不是一个坏主意，但它们只显示直接影响用户的应用程序的一面，因此您不会为任何不是演示的东西获得太多里程。奇怪的是，像 Visual Studio 中的工作流设计器这样的工具可以生成非常清晰的图表，非开发人员也很容易理解，因此如果您的应用程序足够复杂，可以从中受益，它是生成核心应用程序工作流的好工具。
尽管如此，在我多年来使用的所有方法中，没有什么比让用户亲自动手让您知道您对问题的理解程度更好的了。
如果您正在与许多利益相关者和许多贡献者一起处理一个大型且规避风险的项目，那么 UML 建议很有效。即使在这些项目中，开发一个原型展示给决策者也确实很有帮助。通常通过 UI 和典型的用户故事引导他们就足够了。也就是说，您必须注意，专注于决策者的 UI 往往会使他们忽略一些重要的后端问题，例如验证、业务规则和数据完整性。他们倾向于将这些问题视为“技术”问题而不是业务决策。
另一方面，如果您正在从事一个敏捷项目，在该项目中可以快速更改代码（并快速回滚错误），您可能能够制作一个包含所有工作的进化原型。您的应用程序架构应该足够灵活和灵活，以支持快速更改（例如裸对象设计模式或 Rails 风格的 MVC）。它有助于建立一种鼓励实验的开发文化，并承认 BDUF 不能预测软件能否成功运行。
4+1 视图只对技术人员有用。只有当他们足够感兴趣时。还记得你在与客户讨论用例图的最后十几次努力吗？
我发现唯一对每个人都有效的事情实际上是向他们展示你的应用程序的屏幕。你自己说过：一张图抵得上一千个字。
奇怪的是，有两种方法对我有用：
对于选项（1），您可以使用任何您想要的，这并不重要。
对于选项（2），从笔和纸开始是完全可以的。但是很快你最好使用专门的模型工具（只要你需要编辑、维护或组织你的模型）
我最终在 2005 年编写了自己的模型工具，它变得非常流行：MockupScreens
这是我所知道的最完整的模型工具列表。其中许多是免费的：http ://c2.com/cgi/wiki?GuiPrototypingTools