介绍一种好的设计方法——在软件设计前先画界面图

在做软件设计之前，画好系统的界面图是一种非常有效的建模和交流方式。
总是有人抱怨在需求和软件设计之间仍然有很大的鸿沟需要填补，这是至今仍然未能有效解决的软件工程难题。多年以来，有很多人一直在寻找从需求到设计的直接的形式化映射方法，但是收获很少。实际上软件工程对于软件生命周期前面的那些阶段并没有多大的帮助。为了响应 o6z 说的努力在在现有技术基础上杀死人狼的号召，我来推荐一种有效的设计方法。

这种方法其实非常简单，就是不要急于从需求转到软件设计，而是根据需求文档（可以是传统的需求说明书也可以是用例）先画出系统的界面图来。用什么画图呢？你可能立即会想到 Word、Visio、ROSE 一类的工具，我现在告诉你这是错误的做法。你应该采用最快的方式把界面图画出来，因为界面图主要是用来交流的（是给人看的而不是给机器看的），所以你不需要太拘泥于形式。你找些白纸和一支铅笔，马上就可以开展这项重要工作了。如果用白纸和铅笔，我一天最多可以画 20 张界面图，但是用 Word 我的速度可就慢多了，因为我还要考虑排版、美观等等无聊的细节。
你要把界面的布局画的详细些，起码界面上所有的功能点（比如所有的按钮和超链接）应该全部画出来。不仅要画出第一级页面，那些第二级页面、弹出页面、子页面也都要画出来。他们之间的逻辑关系和导航关系都要明确地标记出来。你最好尽量考虑的细致一些以便页面制作人员（实际上我们是由程序员自己来制作页面的，可能又会引起某些人的惊诧和愤慨了）可以参照这些界面图不需要费什么脑子就能顺利把页面做出来，而不是他们做出来后你又要告诉他们这个地方不对那个地方不对。如果你能把这些界面图全部想象出来并且能细致地画在纸面上（当然这个工作并不象这里说的那么容易），那么系统该做成什么样子你就胸有成竹了。使用这些界面图来进行讨论也会比较具体和深入。需求文档总是给人以不够具体的感觉，界面图画出来后，需求就非常具体了（一目了然，程序员因为直接参与这项工作，因此对于需求非常清楚，做开发的时候可以大量减少由于理解上的问题而产生的 bug）。而且还可以根据界面图的数量和复杂度估算工作量，和客户讨价还价的时候心里比较也有底，客户对我们估计的工作量也比较信服。当然你还要尽量把界面设计的美观大方而且容易使用，这方面可以参考我上面介绍的那本书和 Alan Cooper 的《软件创新之路》。

这些界面图需要讨论上两到三次才能定稿，讨论的时候最好能有最终用户的参与，以便尽早获得他的反馈。在这时候发现需求理解上的错误，修改只需要在白纸上重新画几张界面图，成本可以说是最低的。定稿后这些界面图要作为重要的项目文档归档保存。

下一步工作是根据界面图制作出页面，这里我指的是正式的页面（而不仅仅是一个由超链接形成的界面原型），包括全部的 JavaScript 脚本。我们现在创造了一种新的开发方式，可以完全不做后台的开发把全部页面制作好。然后再写后台的代码和配置。因为我们目前工作量的大约 2/3 集中于前台的页面和 JS 上，所以页面全部做好后可以说 2/3 的工作量就已经完成了。

有很多的经验都是软件工程的经典教材中所没有的，难道我们就可以忽略这些经验了吗？有那些项目组是采用这种方式来做开发的？

真想看看dlee你们设计的界面是怎样的！看得出对web表示层，你们公司是积累了不少好的经验的，上次的讲座，你只是匆匆数语，时间有限容不得你了，呵呵！

to Dennis：
其实真的没有什么神秘的，只要你想做，你也完全可以画的出来的。基本上和你们将来做好的页面是一样的（当然可能还会有一些修改，但是结构布局在讨论结束时候就已经完全确定了，美工需要帮助我们的只是调整一下配色、做几个漂亮的图片和有立体感的按钮等等）。画界面图是非常重要的工作，有经验的开发人员在画界面图的过程中实际上已经在思考系统如何设计和开发了，并且会尽量将界面设计的易于开发，因为这些工作都是将来自己要做的，所以他会尽量不把自己逼进死角。
由程序员（当然我作为 PM 要领着他们一起做）来控制页面结构布局是非常重要的，因为只有程序员最清楚系统应该做成什么样子。当然要对程序员的审美能力做一些必要的培训，页面布局要美观大方，不能太难看了。如果有这方面的问题，在讨论时起码我这一关就通不过。

我为什么这么重视界面，因为这确实是非常重要的工作，原因在《软件创新之路》中已经写的很清楚了。界面是软件最重要的外部质量之一，我曾经在这方面摔过跟头，不想再犯同样的错误了。

我再补充一下，不是需要画完所有的界面图才可以做软件设计的（那样又堕入了“瀑布模型”的老路上），而只是需要完成主要的场景就可以了，只要这些功能场景相互独立，并且确实可以独立完成而彼此没有影响。在一个增量开发的团队中，需求搜集、画界面图、软件设计、开发是经常进行的工作。

经过我们长期的思考加实践，我们现在完全有能力定制出一种真正适合于我们的开发过程了，根本就不需要去照搬 RUP、XP、FDD、ASD、Crystal，那只是没有经验的开发团队所热衷的事情。而我实际上并不认为一个标准的过程是杀死人狼的关键，这个观点在《软件工艺》第 15 章：“软件工程隐喻的危害”中已经阐述的很清楚了。

实际上画界面图是对系统的一次建模过程（或者说是一次在开始建造前宝贵的思路整理过程）。如果你能细致地画出系统的界面图，你就非常清楚地知道自己要做什么和系统将来会做成什么样子，而我相信你也一定能做的出来。毕竟知道如何做相对于知道需要做什么还是简单的。如果你连在白纸上都无法画出系统的界面图，我如何能够相信你能做出来呢？ 不是你的技术不好，而是你对要做什么根本就没有深入思考过，根本就没有概念。即使你有匹夫之勇，我如何敢确信你肯定能做出用户真正需要的软件产品来呢？

至于以后的软件设计，我仍然建议你在白纸上做设计，而不是依赖于 ROSE、Together、PowerDesigner 这类的工具。当然我更愿意把这归为个人的爱好，仅供大家参考。

我是用Dreamweaver直接画界面的,因为一般都是普通的BS应用,关键是把上下页之间的联系和数据反应出来

dlee可能你把界面图和界面流程图的概念搞混了，你的意思大概是应该先完成界面流程图，界面图这个东西可以在完成界面风格定义以后的任何时候进行完成。
这个界面流程图是我认为进行一个软件设计的第一个图，同时也是功能分析的时候需要考虑的一个图。但是似乎只有在《敏捷建模》这本书中才提出过这个概念，真的很遗憾。不过我知道很多人都在使用这样的一个工具进行他们的工作。
这个图示非常的直观，当然如果你愿意使用一些真的界面表示这个图示也是很有意义的，不过内容其实是一样的。

Dlee最好补充一下，这种方法比较适用于基于web的系统的开发。呵呵！

我没有看过《敏捷建模》。这种方法是我们自己试验过觉得效果不错的方法。我们对界面图是分成为界面图设计和界面图制作两部分（感觉没有必要按照某本书上那样分，我觉得保持我们自己的特色没有什么不好）。界面图设计就是在白纸上画界面图，要达到能够直接制作页面的详细程度，所以就不只是界面流程图了。
程序员制造的 bug 有很大一部分是因为他不理解需求（根本就不知道要做成什么什么样）造成的，这样的方式程序员很早就参与进来，就会大大减少这样的问题。

上次庄表伟说 XP 中从来没有界面设计人员的位置，我觉得这确实是一个问题。哪怕象我们这样由程序员来做页面，也至少应该有界面设计师这样一个角色存在。

to jebtang：
确实比较适合 Web 开发，至于这种开发方式是否还适合其它类型的开发我还没有想过。

其实很多行之有效的东西都是我们自己总结出来的，但是过后一看很早以前就有人在用了。这不能不说是一种交流的不充分的结果，但是也显示出其实有效的东西会在不同的环境中自然的发展起来。

另外的原因也是不自信还有越是简单有效的东西我们就会越去忽视去promote它.
因为那个比起什么OO,什么Use Case理论什么的都不值一提,根本没有"学术价值"