在这里仅仅讨论如何去做 prototype , 那些是必须的， 那些是可选的。
此POST 的理由是 我和我们部门经理对于什么情况下需要做prototype 、 那些是prototype必须的， 那些不是必须，的理解不一样。
（一） 快速原型方法 的理解
快速原型方法就一种开发方法。在软件开发过程中，最关键的步骤就是确切定义出需求，明确软件要实现的功能是什么，而这恰恰也是最困难的过程，因为现在许多用户在初期只有一个隐约的、大致的考虑，根本不可能提出具体明确的需求。这种情况下，使用快速原型进行反复交流、细化需求，就成为一种更加有效的方法。一个软件的原型，主要是模拟重要的功能和界面，但是一般不考虑运行效率，也不考虑系统的健壮性，出错处理也考虑不多，它的目的只是为了实际描述概念中的结构，使用户能够检测与其概念的一致性和概念的可用性。（ 一般我们做的系统， 需要界面， 界面元素不是非常简单的， 都可以使用这个方法）
目前主要有两种快速原型设计方法：
· 丢弃原型（Throw-away prototyping）。其目标只是为了明确需求，使用最简单的开发方法，以最低的成本实现一个可工作的系统，该系统只关注功能，不考虑开发工具、性能、容错、未来实际运行环境等。通过反复与客户交流和修改原型，使原型的功能能够充分体现客户需求。在明确了需求之后，原型就会被丢弃。以后软件的开发将根据明确了的需求按照传统的工程化方法来开发。
· 进化原型（Evolutionary prototyping）。其目标就是与客户一起工作，从一个原始的需求的轮廓开始，逐步改进，最终发展成为符合实际需要的系统。采用这种方法，就需要考虑到软件未来的运行环境等有关要求，这就要求从一开始就要对需求有一个比较清晰的认识，不能有方向性的错误。
快速原型方法存在的主要问题是：文档容易被忽略，建立原型过程中的许多工作会被浪费，项目难以计划和管理。但是这种方法的好处更大：能够适应不明确的需求，比传统的瀑布式方法要快得多，用户的介入更多，能够及早发现问题从而降低风险。 在软件开发过程中，面对快速变化的市场需求和新技术发展，最大的风险往往来自对需求的分析和技术实现手段的选择，通过原型化方法，首先以合理的成本细化需求、试验技术手段，把最主要的风险降到最低，从而在总体上降低软件开发的风险，加快软件产品的形成，降低软件开发的成本。
( 二) 具体做法
根据客户已经描述出来的需求， 做出Page static View、Dynmic View ， 使客户和开发团队之间有一个共同的具体讨论对象。
比如做一个web 应用系统，
原型必须展现出 业务应该有的属性， 栏位， 排列方式， 使用的控件的类型， css 表示。
有流程的话，需要表示出流程的流动出来。
不是必要的：
模拟动作的数据问题， 比如submit 一张单据，产生一张新单据等等 。。。
界面的风格也不是必要的。 ( 这部分可以单独和客户谈) .
前面也说过， prototype 方式追求的是 快速的开发界面原型和用户讨论需求， 我们追求的是理解上的一致。 我们不必要吧原型做的非常的漂亮和一字不差，那样的话， 项目的周期和成本都有很大的增加。
切忌。
