References
Wiki = Wikipedia
SA = Scrum Alliance
MG = Mountain Goat Software
C2 = Cunningham & Cunningham
AM = Agile Modeling
JS = James Shore
XP = Extreme Programming
IXP = Industrial XP

上篇需求方法之－原型开发讲过制作原型是业务人员应该掌握的一项基本技能，这篇主要给大家介绍一个我认为比较好的一个工具：GUI Design Studio，大家可以到官方网站下载试用，如果用于个人学习，也可以上网搜到破解：）

软件帮助文档有个记事本的例子,如果参考做完就能大致了解如何做原型了. 下面我主要示例一个管理软件常用的界面模式，登录后显示主界面，主界面上面一个公司图标，左边为一个功能列表，点击列表时在工作区页签显示相应的模块窗体。做了一个视频,方便大家更好的快速了解.

主界面

上面为菜单和工具条，工具条主要用的就是连接线，菜单主要用的是Design－Addbitmap添加图片（我也是刚找到的，应该在右边Elements上更好）

右边为界面元素和文档目录管理：

  Project：管理文件目录层次，可以在根目录下放主界面，然后把功能模块分系统新建多个目录保存。对于界面窗体比较多时，尽量按照模块目录分类来保存，千万不要放在一个页面中设计，否则以后就不好维护了。
  Element：界面元素，比如按钮、工具条等界面展现的控件
  Icon：图标，可以软件的安装目录里加入自己的图标后应用在项目中
  Storyboard：增加动态控制界面元素的动作控件。用的最多的是windows placeholder，主要来做显示在Tab页的内容，可以查看软件的帮助文件的索引 Working with tabbed interfaces进一步了解
  Note：给控件加标题和注释，如果加了注释，在原型运行时鼠标放在＃上会显示提示

演示：录制movie和demo在大米盘下载

业务人员主导原型工作

需求在产品开发中的重要性已经是不需争议的事实，现在需求方法有很多，业界最常用的一种办法就是通过原型展现需求，通过用例表达需求。业务人员掌握制作原型能够更快更清楚的表达业务，同客户和开发可以进行更直观的沟通，使得大家在理解上容易更一致。然而原型工具有非常多，比如大多数人用过的Excel、Access、Delphi、PowerPoint、Axure、Balsamiq Mockups、ForeUI、iRise、Lucid Spec、Mockup Screens、Pencil、Serena等，甚至开发工具雅奇等也可以用来做原型。工欲善其事，必先利其器，对于刚刚使用原型方法的业务人员来说，如何选择适合自己的原型工具呢？这就需要首先根据原型的目的明确做原型的粒度。

根据工作现状选择做低保真原型还是高保真原型

原型分低保真原型和高保真原型，低保真原型目标在于表达工作主要内容，体现静态的元素，不需要动态交互。高保真原型目标是作出一个和实际上线后的产品差不多的样子，不仅包括静态的界面，还包括交互，甚至有的还把数据保存、逻辑验证等都包含在内。如果客户要求开发之前必须看到和实际产品一样的原型时，这时就需要做高保真原型，如果对于小型项目，或者只是用来做交流主要需求用时，就可以做低保真原型。

我们可用作介于低保真和高保真之间的原型

在限定时间内能够将需求表达更清晰需要一个合适的工具。业务人员一般都不会有什么编程经验，我们怎么能够做出表达静态元素界面，又能加入动态交互功能的原型呢？为了能在需求阶段都能够更好的采用原型开发方法，我搜集并使用过多种原型工具，希望找打一款比较使用简单，但又能实现一般的交互功能，最好是业务人员学个一个小时就可以完全自己动手使用了。我用过一个原型工具 GUI Design Studio ，它的主要特点就是操作简单，不需要开发人员帮助，通过半个小时的学习后你将可以自己开始做原型了。后面我会对这个工具的使用进行介绍，希望有更多的业务人员能够更好的应用原型来进行需求开发。

原型不仅仅是需求，它还是设计

我们可以通过原型来引导用户来使用系统解决问题，但原型不仅仅是需求，它还是设计，所以作原型时不仅需要客户的参与，也需要技术人员的参与，但应该尽量由业务人员而非开发人员来实现原型，这样才能更好的保证做需求不会演变成做开发了。下面是在UCD社区里面看到的一张图，原型最主要功能是表现界面，但要做好界面其实不容易，山下面还有很多东西需要考虑才能支撑界面，其实做原型的过程就是设计系统的过程。我们都希望尽量把开发工作前移，需求能做的工作就不留到开发环节做。如果软件模式一定，那么框架做得好的话就一定可以能够让业务人员业务人员就做一部分属于开发人员的工作（这部分工作本就该属于业务人员），那时大家就能体会到开发软件就如同做原型一样的乐趣了！

经常有人问我是如何学习的，有什么办法可以学得更好？我认为学习最好的方法其实很简单，那就是坚持，坚持学习，坚持实践，坚持思考。

每天基本上都要学习，坐公交时会拿着手机看电子书，平时工作多加思考，晚上会根据自己对技术的判断进行知识的搜集和学习，我从工作到现在就是这么一直坚持学习的，我很多大学同学都不太相信：）

学习如同加班，也是在业余时间付出额外精力，只不过是学习是主动，加班是被动的。不停的学习，就和不停的加班一样，会使我们处于一个满负荷运作的状态，不可避免的在某一时刻会感到劳累，这时我会停下来休息，和家人去外面度度假，或者连续打几天游戏，用一些办法来舒缓一下疲劳。其实这只是体力带来的疲劳，还有一种疲劳是只见不断学习而不见成果的假学习。这时就要尽量抓准时机坚持实践，只有通过实践回报不断学习的毅力才能达到真正的快乐学习。

而不断的学习、实践是要基于某一些内容来做的，我们不能太贪心，什么都想做，这时就需要不断的坚持思考，思考存在哪些问题，思考自己能解决哪些问题，怎么通过学习和实践来解决。

在确定了某个领域的问题后，就可以通过很多方式来进行学习了：

1 blog订阅：对感兴趣的blog进行搜集，每天都会花一些时间来查看，以便持续学习和关注。《如何阅读一本书》中说到太多的资讯就如同太少的资讯一样，都是一种对理解力的阻碍。当我们订阅blog一定时期后，你会发现已经blog列表已经很长了，这时就需要进行整理一下，否则会发现自己像无头苍蝇一样看很多内容。大家可以通过很多blog订阅工具，我喜欢用google reader来订阅blog。

2 书籍：书籍一般都是经过作者大量思考和实践总结的一些知识，通过别人的总结可以系统的进行学习，这也是我对不熟悉的知识进行系统学习的一个主要途径。现在好多电子版书籍都可以通过网站找到，也可以在豆瓣上管理自己的读书数目

3 网络搜索 ：这是我们大家都常用的方法，一般用来解决当前遇到的问题

4 还有其他一些方法，如写blog、写示例、研究现有产品、给其他人培训和交流、实践中反复思考验证等

　　在我以往工作中就有过所谓的“责任”，即使当前的工作与自己意愿不一致时也非常尽心，跟随着大部队加班加点，但最终没有给公司客户带来什么实质的作用，有时想到责任，我反而觉得责任不只是以往的定义，只做分内的事情，有时我们需要停下超负荷的脚本，静下来思考一下达到目标的更好方法，坚持自己的想法，而不只是循规蹈矩的只做份内的事情。有了对责任的这个定义后，有次工作中我竟然会拒绝接受一部分工作而专心做自己认为该做的工作，后来自认为还很满意，比起以前所谓的“责任”要好得多。所以，责任不仅仅是只做分内的事，有时需要去除部分责任，扩充一些责任，对责任做到真正的负责。

在《软件工厂方法》一文中，我介绍了领域工程的基本介绍，领域工程由横向领域和纵向领域组成。平台概念很早就有，我认为对管理软件来说，平台就是能够在纵向领域上研究透业务的基础上使用横向领域的成果来一起来搭建一个满足用户需求的应用。
1. 纵向领域（vertical domain）：根据系统类别而组织的领域。如预算软件、材料管理、合同管理、企业报表系统等。
2. 横向领域（horizontal domain）：根据软件部件的类别而组织的领域。比如元模型引擎、报表引擎、工作流引擎等。
3. 领域之间有3中类型的关系：
a) 包含：比如成本管理软件包含了材料管理系统
b) 使用：比如管理软件都使用报表引擎，OA系统都使用工作流引擎
c) 类似：领域之间侧重点不同，但有很多的相似性，通过深入研究一个领域，可以取得对另一个领域的更好理解。比如报表引擎中对于表达式解析和索引部分可能与数据关系计算引擎类似。
大部分书籍也是像以上那样简单介绍一下基本定义，以下我从它们在产品线开发中的关系来发表一下看法。

经常有人讨论业务和技术的关系，希望争论出到底哪个更重要。如果从商业角度来说，最终的目标都是通过满足客户的需求实现双赢，而业务和技术都是实现 这个大目标的方法和工具而已，业务的深入是让我们能够做正确的事情，技术是让我们能够使用适合的解决方案来正确的做事情，两者必须协调一致才能实现最终的目标。

在认识了这两个领域都很重要的前提下，公司观点不一样，投入可能会出现三种情况，先业务后技术，先技术后业务，技术和业务同时进行。

• 先业务后技术

　　认为业务是技术应用的前提，所以必须完全弄清孵化了业务后才开展技术工作。当业务随着投入有所进展后，开发技术也越来越多不只是简单的增删改了，很多技术其实本应该是由纵向领域去解决的事情了，一年半载就这样过去了，本想着这样对付过去了，等业务请出来再技术重来，但是随着业务深入，用户的使用越来越多，销售和用户已经不能在等你重新进行纵向领域的应用了。先业务后技术的方向，在不是很好管理下即有可能变成了只有业务了，但是会出来产品。

• 先技术后业务

　　认为软件公司没有技术是不行的，所以技术优先。在技术上投入，Vista来了研究Vista，新的语言出现了研究新的语言，派专人进行研究，这种方向下会出现两种结果。如果研究人员本身目标明确，技术可能会成功研究并应用回报公司，也有可能遇到一个本身目标就不明确的研究人员，不知道研究的东西有什么用处，越研究反而越茫然，结果导致公司误认为这个对公司没有什么价值，最后就不了了之。所以先业务后技术的方向，在不是很好管理下即有可能变成了只有业务了。先技术后业务的方向，运气好的话会皆大欢喜，运气不好的话会没有人和成效，反而可能会把有用的技术当成没有的东西。

• 技术和业务并行

　　认为技术和业务是互相关联，缺一不可的，所以会在技术和业务上分别投入人力，并随着回顾两边的情况，不断协调进展。架构框架设计在了解部分需求下就可以进行了，技术的实现对业务也会有影响。在并进过程中，会出现先分后合的情况，因为开发产品时，业界已经有很多模式可以应用。比如你做企业管理软件，做OA，则工作流引擎，报表引擎等纵向领域必须有，公司可以在这方面先期投入而不用等到用户马上要了再来开发。

以上三种方向，我们该采取哪一种呢，我想这个需要视企业情况来看，如果企业发展初期，那么先业务和技术，先把业务吃透了，提高企业在行业内的知名度比吃透技术要紧，对于已经发展不错的企业，则应该采用技术和业务并进，不断的在业务和技术两方面协调发展。而如果企业已经衣食无忧，那么可以先技术后也业务，因为在业务不是很明确的情况下，技术也可以带动业务的发展。

技术和业务并进在第三类公司可能占多数，所以我们在投入时也需要认清他们的关系，哪些该并行进行，哪些该先后串行，不同领域由哪些人用什么方法完成，进行过程中如何不断回顾提炼方法。做开发和其他事情一样，开始之前没有具体的目标是绝对不行的，没有目标，推进研究像前是没有必要的，毫无意义的，但是一旦有了目标就不同了，有了具体目标后就算研究进行不下去了，也有那个具体的目标作为前进路线上的防线，指示着要走向哪里。有时候目标也会变化，或者更高，或者有所降低，如果目标更高了，当然相应最终结果也会更好。

软件产品线范围很广，有技术、管理、人员各方面的内容，包括纵向领域和横向领域，每个领域里面又包含很多领域。我们在开始之前又该如何确定我们的目标呢？一般制定大目标时，都会通过将目标拆解为多个小目标来细化，然后由不同的人各自实现小目标，在实现过程中并不断的回顾小目标对大目标的影响。

在《软件工厂方法》中讲过产品线的四个核心：范围、通用性、可变性和扩展点。纵向领域提炼出721，横向领域为纵向领域提供支持，比如基础设施的支持（各个需要的引擎）最好先期投入，这样当业务进展到一定阶段时，技术的支持就会很顺利了。

如果我们知道了作企业化信息管理软件，工作流、报表必需要存在，那么我们可以先期投入人力解决这一块。但是我们又如何保证这些小目标的投入可以给公司带来真正的回报呢。我想每个小目标都需要先从以下几点明晰自己的目标：

• 愿景和任务：是否能够使用一句话简单的说明自己的愿景和任务？
• 涉众：谁是你的客户
• 问题：关注哪个领域或者问题
• 业务价值： 提供什么价值?产品的价值是在大蛋糕中的哪一块？
• 如何度量成功: 用什么来表示成功?
• 产品线: 给产品线提供了什么?

以下两篇为我以前关于技术和业务的简单观点，相对于上面的浅显一些：）

再谈技术和业务的关系    

业务、技术和语言的关系

1 Don't put your resume ahead of the requirements

As engineers we sometimes recommend technologies, methodologies and approaches for solving problems because deep down we want to have these on our resume and not because they are the best solution for the problem. Such decisions very rarely result in happy outcomes.

作为工程师，我们在解决问题时提出的技术、方法和方案时实际上是为了让自己履历上拥有更多的资本，而不是应为这是解决问题的最好方案，这样将往往很少能有成功的结果。

The best thing for your career is a long string of happy customers eager to recommend you because you did the right thing by them and for the project. This goodwill will serve you orders of magnitude better than the latest shiny object in the latest shiny language or the latest shiny paradigm. While it is important, even critical, to stay abreast of the latest trends and technologies this should never happen at the cost of the customer. It’s important to remember that you have a fiduciary duty. As an architect you have been entrusted with the well-being of your organization and its expected that you will avoid all conflicts of interest and give the organization your undivided loyalty. If the project isn't cutting edge or challenging enough for your current career needs then find one that is.

     工作中最好的事情是有很多用户因为你为他们的项目做了正确的解决方案而乐意推荐你，这样的好信誉比起会用最炫的语言要有益得多。虽说掌握最新的技术和发展趋势非常重要，甚至对非常关键，但是你应该牢记你的职责是为客户服务，需要为客户提供最好的解决方案，而不是牺牲客户的利益来提高自己的技术。作为一名架构师，组织非常信息你，并且期望你能够处理所有利益冲突，对公司也能够保持高度的忠诚。如果当前的项目对你职业生涯发展没有推进或者不具有挑战，那么最好的办法是去寻找一个满意的项目。

If you can't do that and you are forced to be in such a project, then you and everyone else will be happier using the right technology for the customer rather than for your resume. It’s often difficult to resist utilizing a solution that is new and cool, even when it’s inappropriate for the current situation.  

      如果你找不到合适的项目，并且被迫在这样的项目下工作，那么你和大家应该乐意使用正确度技术为客户提供解决方案，而不只是为了自己的履历拥有更多的技术。即使当当前形式不利于使用新的或者酷炫的技术时，抵制利用这些带来的诱惑也是比较难的。

With the right solution, the project will have a happier team, a happier customer and overall far less stress. This will often give you time to go deeper into the existing older technology or to learn the new stuff on your own time. Or to go take that painting class you always wanted to do. Your family will love you for it, too - they'll notice the difference when you get home.

     使用正确的方案，项目将有一个快乐的团队和满意的客户，大家也感觉不到什么压力，这可以让你有更多时间深入精通已有技术或者有更多自己的时间去学习新的技术，甚至有时间去参加绘画兴趣班，当你回家时你的家人也能感觉到你的变化，并更喜欢你这样。

Overall always put the customer's long-term needs ahead of your own short term needs and you won't go wrong.

     总的来说，牢记用户的长期利益高于你个人的短期利益是不会有错的。

　　我认为代码、口头交流和文档都很重要，我们不能绝对的站在任何一边。在敏捷过程中不能要求非常详细的文档，也不能误解敏捷开发而不要任何文档。《敏捷文档》描述了面对面沟通和文档的一些主要特点：

　　通过以上对比可以发现，面对面沟通和文档并不是对立的，而是互为补充的，就像我们读书学习一样，我们需要从书本和老师的授课中学习。

Textual v Graphical models

What is the best open source MDD code generation tools ?

What about pragmatic approach to model driven development?

Book Recommendations on MDSD and complementary areas

Advocating Model Driven Software Development

Model-Driven Development is dying - discuss

How can we make this succeed?