先可视化，再构建

在软件开发项目中，各参与方之间沟通的重要性不言而喻。图形化模型和类似的可视化对加强沟通来说，其能力也同样显而易见。更棘手的问题则在于决定使用何种可视化，并判断在开发过程的哪个关键点，可视化最有用、自动可视化工具又能提升价值？

《计算机世界》最近发表了由Esther Shein撰写的文章先可视化，再构建：模拟工具的优势，Shein主张在开发过程初期就全面使用自动可视化工具。该观点与传统的瀑布开发方法一脉相承。Susanna Goldenstein在近期发布的网络讲座利用需求的可视化：一家生物科技公司的敏捷案例分析中建议使用可视化工具，但使用非传统的（敏捷）方法进行开发，也可以同样有效。文章和讲座都谈到了自动化工具iRise，iRise被描述为“企业级的可视化平台”，可用来快速装配业务软件并进行工作预演，模拟最终产品的具体外观、体验和行为。

Shein在文章中建议，对用户界面进行可视化、对业务流程进行建模、模拟用户交互的自动化工具要优于更为通用的工具，比如主要以文本格式描述大量系统需求的电子表格。Goldenstein的网络讲座则指出，对于故事卡片这一主要的敏捷沟通工具来说，可视化工具是必要的增强，或者可以作为替代品。

Melinda-Carol Ballou是IDC公司（位于马萨诸塞州弗雷明汉）的分析师，他认为好的需求很重要，尤其在现如今的经济形势下。Shein引用了他的这一观点。

设法与软件开发人员沟通需求对业务利益相关者来说已是老生常谈。但在经济不景气的情况下应对这一挑战变得更为攸关。资源日益稀缺，不能有任何闪失。如果创建的内容脱离实际的业务需要，失败的成本会更加显著。若能让需求可视化并展现在屏幕上，这就为用户提供了有形的东西，能让他们看到具体的内容。

Shein建议，要想更好地描述需求，还应该处理好“缺陷”项目和“失败”项目中那些众所周知的问题。

Standish Group的报告指出，2006年到2008年，项目成功率一直呈递减趋势。……根据Standish Group的报告，2008年出现延期、超出预算、或是没有完成所有特性和功能的项目（缺陷项目）大约占44%，还有24%的项目或失败、或中途取消、或弃之不用。2006年的项目失败率仅为19%。

如果需求可视化工具能改善这种情形，其价值就显而易见了。该类工具到底能有多少实际帮助呢？很多人认为这些工具必不可少。在竞争日益激烈的市场里，iRise只是其中一个角逐者。《计算机世界》提到的可选工具包括：

• CSS框架Blueprint
• RavenFlow，提供可视化的需求定义软件，旨在将英语文本解析为结构化的需求。
• Blueprint需求中心，为需求定义提供基础设置，包括业务流程图、用例、UI原型。
• 微软的Visual Studio 2010 Ultimate及其Expression SketchFlow产品，为需求可视化和生成应用界面故事板提供了好几种工具。
• IBM提供的Rational Jazz平台，其中的Rational Requirements Composer有助于团队在整个项目生命周期内有效定义和使用需求。

这些工具都能以图形化方式描述用户界面、模拟用户交互，并以图形化的方式为业务流程和逻辑进行建模。

正如Shein所指出的，完整、准确、明确地描述系统需求并不是新近才出现的问题。Fred Brooks在《没有银弹：软件工程中的根本和次要问题》中表明，软件概念的缺失（心理表征或视觉表征）才是本质困难。

自该问题出现以来，人们就尝试使用自动化工具来描述需求了。Dan Bricklin是Visicalc的联合创造者（Visicalc是第一款商业电子表格，往往被誉为引发台式计算机革命和苹果初期成功的“杀手级应用”），他在二十世纪七十年代创建了“快速原型工具”Demo，Demo能用图形描述用户界面，并能模拟这些界面的基本交互。使用这些工具的价值在于加强沟通、提高客户对软件界面的满意度，该价值在Demo中得到了明确体现，随即许多类似产品开始跟风Demo。随后的几十年里，阻碍该类工具采用的问题有两个：第一，原型的概念备受争议，软件工程的倡导者们嘲笑原型危险而又容易出错；第二，用户的期望不对——看到完整的原型，用户往往以为应用已经基本完成了！

人们认为需求可视化工具的市场正在不断增长，预计到2013年，会从2007年的1.94亿美元增长到2.9亿美元。这并不是爆炸性的增长，而且现在更加先进的产品能否提供先前产品不具备的功能也尚待分晓。

查看英文原文：Visualize First. Build Later.