大家是否有这样的想法？

=============
我理解就是做出来先做出来demo作为需求分析的基准，
然后跟客户和team成员讨论确定最后的成果物。
当有需求变更时候，也先改变demo，在修改程序。
日本外包基本都采用这种模式。
好处是，用户需求和成果物偏差小
坏处是，浪费时间，有做demo的时间，编码都快结束了。
---------------
另：我认为日本的软件工程方面很值得国内软件业学习。
别拍我

原型法？了解软件工程历史的人都应该知道是什么东东吧。而且它和迭代进化法的历史渊源也有很多文章在讲哈

所以这个东西根本就是扯淡
居然还总有人说敏捷等价于这样的东西

xp里的 用户story 是否也有可能需要 原型来辅助呢？

纸上画，白板上画，画完就擦掉撕掉
原型是在没有可工作的软件之前用来帮助沟通的，一切的沟通最终要落实到可工作的软件
一边做软件，一边还维护一套原型，那根本就说明(1)客户没有频繁的沟通；(2)团队没有频繁交付的能力
所以我又学到了一个经验：但凡说敏捷就是原型+迭代的，在这个组织的沟通和质量两方面多半能找到严重的问题

楼上对项目管理感兴趣的，可以上电驴下载“上海交大IT项目管理”的课程，很系统的讲解IT，由其软件开发的生命周期管理。

XP里的 用户Story 并不是用 原型 来辅助，而是指将需求尽可能的细化到单次迭代上去，这样就形成了一张张卡片（用户Story）然后每完成一次迭代就和客户沟通一次，确认本次迭代的成果，收集用户的改进意见放入下次迭代（或下下次迭代，不能拖得太久），确定下次交流时（即下次迭代的）的内容。每次与客户交流时都是用真正的可交付的系统在交流，这样才会使软件尽可能的满足客户的需求。

国内做对日软件时所谓的prototype主要是指
1.技术检证
包括framework构造，feasibility检证，performance检证乃至ha检证等
这里所做工作主要是为了找出正确的技术手段去满足非业务要件(SRS)，一定程度上是属于项目的前期风险控制行为。

2.代码示例
主要是系统典型的业务处理pattern的例子代码（一般使用真实的usecase，usecase选定通常需要开会，基本上要求业务简单，容易把握的usecase,比如对MASTER表操作的usecase），比如online transaction中的CRUD各操作涉及到的所有方面（表现层的用户体验有什么样的约定，各层程序该怎么写，怎么交互，配置文件怎么配，也包括log怎么打，exception,message体系等，甚至包括代码中所遵循的编程规约)。
这可以认为是由对日外包的特性而产生的针对大规模编程人员的一种项目培训行为，

其中1通常是在基本设计前期（HLD)开始进行，2通常是在详细设计(LLD)中后期组织一个小而精的team去做的，
基本上和业务上的需求分析无关，也不应出现用户需求改变时，还要再去维护prototype的case.

不如用netbeans的jsf可视化设计好了,比dr还带逻辑的.

我们一般做好类似demo给演示的