关于原型法的讨论——与Wonder的对话

类别:软件工程 点击:0 评论:0 推荐:

2004-11-10 16:57:06 Wonder
原型分为多少种?

2004-11-10 16:58:08 青润
实用性原型、演示性原型,主要是这两类。
在这上面还衍生出了一些其它的原型概念,例如:渐进性原型、抛弃性原型等等
 

2004-11-10 16:58:32 青润
这是我目前的看法。没有见到过很详细的介绍原型法的资料。
 

2004-11-10 16:58:56 Wonder
我需要的是严格定义

2004-11-10 16:59:03 Wonder
就是名词,

2004-11-10 16:59:32 Wonder
其实里头的抛弃和渐进和上面的演示/实用的说法差不多

2004-11-10 17:02:27 青润
不一样,实用性原型的结果是不断演进的,如果是一步一步推进,而不是一步定位的做法,那就是渐进。
同样演示性原型,如果要求每一次的原型必须被抛弃,并重新构建,那么获得的九时抛弃性原型,否则,就是渐进性原型
 

2004-11-10 17:03:09 Wonder
但原型并不一定是非要演示用

2004-11-10 17:03:41 青润
但是,有些是在系统开发之前出来的,就主要是为了演示功能,因此称之为演示性原型。
 

2004-11-10 17:04:26 青润
如果是系统开发完成以前,经过快速补充形成的原型,也就是说具有一些实际操作功能的原型,那就是实用性原型。
演示性原型中没有功能的实现,这就是两者的差异。
 
 

2004-11-10 17:04:58 Wonder
我觉得分为可抛弃原型和实用性原型,别的是个方式问题

2004-11-10 17:05:31 Wonder
有时候也很难说就全部抛弃,从头开始。论证需求和功能也必然是个渐进的过程,如果一次性都想明白了,那还抛弃干吗。

2004-11-10 17:06:03 Wonder
所以最后的标准应该是到底留下不留下原型作为开发的基础,而不是方式问题。

2004-11-10 17:06:48 青润
不,抛弃性原型就是一种要求全部抛弃前面做的内容的原型法。每一次都要对前一次进行彻底的改变,甚至不包含任何一点相似点。这种做法比较极端,但是,却很有效果。
 

2004-11-10 17:06:56 青润
应该说在一些场合是非常有效果的。
 

2004-11-10 17:07:22 Wonder
那依然就是抛弃型和实用型的划分

2004-11-10 17:07:31 Wonder
而不是演示/实用的划分

2004-11-10 17:07:48 青润
演示/实用的划分我已经说过了:演示性原型中没有功能的实现,这就是两者的差异。
 

2004-11-10 17:08:14 青润
演示性原型中才存在抛弃性的做法,实用性原型中是不存在这种做法的。
 

2004-11-10 17:08:19 Wonder
我不同意,

2004-11-10 17:08:35 青润
不是你是否同意,这是大家都在做的事实。
 

2004-11-10 17:08:45 Wonder
即使演示型原型,这些演示也可以用于未来的UI,用是否有功能作为划分原则是不合理的

2004-11-10 17:09:00 Wonder
你总不会不承认UI是工作的一部分吧?

2004-11-10 17:09:10 青润
呵呵。我觉得,你可能需要详细的看一下原型法方面的定义。
 

2004-11-10 17:09:30 青润
这样做是有原因的。这样的划分和做法也不是无中生有的做法。
 

2004-11-10 17:09:47 Wonder
那你解释一下为何如此划分的道理?

2004-11-10 17:10:07 Wonder
那干脆不要写原型就好了。

2004-11-10 17:11:01 青润
实用性原型到最后会直接推导出系统。而演示性原型的所有的内容大都是用作引导用户需求的,因此在演示性原型下不会存在任何功能的实现。
(不要把界面和功能实现混为一谈。这两者是有差异的,界面的做法是为了方便用户操作和使用功能,而不是实现功能)
 

2004-11-10 17:11:52 Wonder
不对,捕获需求给用户看的肯定包含UI的部分。

2004-11-10 17:12:07 Wonder
至少UI的界面元素,而不仅仅是操作和使用功能。

2004-11-10 17:12:30 Wonder
而这些元素几乎毫无例外会被用户确认一些,然后作为设计依据。

2004-11-10 17:12:33 青润
原型的出现是为了降低后面开发过程中带来的需求变更而提出的一种提前实现的方式,这种实现方式并不是实现得很完整,而仅仅是可以让用户提前看到系统完成以后的状态,让用户提前能够把自己考虑到的新的功能方面的要求提出来。
同时这样做也是有助于对整个系统的评估度量的。
 

2004-11-10 17:13:29 Wonder
这方面不应该按照书本去说

2004-11-10 17:13:45 青润
不是照书本说,我个人的感觉也是如此的。
 

2004-11-10 17:14:01 青润
你如果说Ui也是需求,我不否认,但是那不属于功能性需求。
 

2004-11-10 17:14:35 Wonder
比如你画了几个web网页,用户确认了。你把他重新丢弃,但web网页本身就包含着一些功能,例如支持鼠标操作,支持快捷键,这不算功能?

2004-11-10 17:15:11 Wonder
还有网页的表现形式被用户确认后,你会完全抛弃自己再重来一个? 

2004-11-10 17:15:25 青润
呵呵,那都是系统功能以外的功能实现,不属于系统的业务功能。你不能说为了和微软的操作系统区别开,我们新的系统就不是用鼠标。这是不一样的。
 

2004-11-10 17:15:34 Wonder
还有操作的顺序和交互的方式,这不算功能? 这些东西都很难一下子切开

2004-11-10 17:16:20 Wonder
那比如说交互方式呢? 比如用户要求采用右键弹出式菜单,这算功能需求还是界面需求?呵呵

2004-11-10 17:16:26 青润
我还是觉得,你应该先去了解一下,然后我们在继续讨论这个问题,如何?
 

2004-11-10 17:17:08 Wonder
那我就不说原型就好了,实际在作的时候大家都是那么作的。最后无非是抛弃还是继续罢了。
 

2004-11-10 17:17:13 青润
右键弹出菜单的建议,不属于业务性需求,最多属于附加需求,如果我不能实现,我同样可以告诉用户按一个按钮来实现,这样用户也是可以接受的。不是么?
 

2004-11-10 17:17:31 Wonder
所以演示/实用这种划分标准是不对的。

2004-11-10 17:17:47 Wonder
你错了,你刚才说的是按照功能划分,可不是按照是否业务需求划分

2004-11-10 17:18:02 青润
功能的直接映射是什么?
 

2004-11-10 17:18:30 Wonder
什么叫做功能的直接映射?呵呵。你先定义一下

2004-11-10 17:18:47 青润
就是说,功能是从哪里获得的?
 

2004-11-10 17:19:06 Wonder
也可以是想象的。

2004-11-10 17:19:11 Wonder
这就不是捕获的。

2004-11-10 17:19:27 Wonder
我不反对大多数原型的定义

2004-11-10 17:19:23 青润
其实,想象也是一种捕获。
 

2004-11-10 17:19:33 Wonder
但我觉得你的分类标准不对。

2004-11-10 17:19:41 青润
嗯。呵呵,这只是我目前的看法而已。
 

2004-11-10 17:19:50 Wonder
那你硬要扩展,那一切概念都是关联的,那我也没啥好说了

2004-11-10 17:20:20 青润
不是硬要扩展。而是我认为这样比较容易控制,在概念上也是说得清楚的。
 

2004-11-10 17:20:40 青润
他们的关联关系也是如此。从来没有人会拿实用性原型来做抛弃法处理。
 

2004-11-10 17:21:05 Wonder
我觉得应该是抛弃/实用,然后在方式之下,才是渐进的,还是一次性重构的,在功能上是演示的,还是验证构想的。

2004-11-10 17:21:35 Wonder
演示是一种面向用户的模式,不能和实用对等。本身看问题的角度也不同。

2004-11-10 17:22:03 青润
不,我不这么认为。
我认为实用/演示是从后台到前台的划分方式,而抛弃,只是一种处理手段。
 

2004-11-10 17:22:49 Wonder
不对,如果我只是为了验证自己的构想,我根本不演示给别人看,这个演示的说法就无从存在。也无所谓后台/前台。

2004-11-10 17:23:10 Wonder
如果你是项目你画给用户看,当然是有阶段的。所以这么说是有条件的。

2004-11-10 17:23:24 Wonder
一个角度是客户的,一个角度是开发者的选择,这两个角度不能对等说明。

2004-11-10 17:23:25 青润
那就是你自己在玩了。实用不实用也没有必要了。所以,抛弃不抛弃也是没有必要的。
 

2004-11-10 17:23:32 Wonder
但可以分列说明才行。

2004-11-10 17:23:37 青润
原型,就是为了给别人看的,否则,还叫什么原型呀。
 

2004-11-10 17:23:58 Wonder
青润 17:23:24
那就是你自己在玩了。实用不实用也没有必要了。所以,抛弃不抛弃也是没有必要的。

这种情况在作产品的时候当然存在

2004-11-10 17:24:21 Wonder
那你写一个东西,验证自己的思路和想法,这不叫做原型叫什么?

2004-11-10 17:24:18 青润
比如说,你自己在文档上画了一张图,这样也属于原型,就是演示性原型。我认为。
 

2004-11-10 17:24:26 青润
对,就是这样的。
 

2004-11-10 17:24:40 Wonder
我不认为,没有谁心理很明白事情,然后演示给自己看

2004-11-10 17:24:38 青润
因为他没有任何的功能实现。
 

2004-11-10 17:24:56 青润
那你说叫什么?
 

2004-11-10 17:25:03 Wonder
我也完全可以将功能实现,然后验证这么作可行。

2004-11-10 17:25:16 Wonder
但是推翻了按照别的方式去实现。对不对?

2004-11-10 17:25:23 青润
那就是后面的事情了。功能实现的时候,你做得就不是原型了,而是开发了。
 

2004-11-10 17:25:31 Wonder
或者按照更优化的方式去实现。

2004-11-10 17:25:45 青润
是的。这样的选择可以在任何阶段采用。
 

2004-11-10 17:25:51 Wonder
呵呵,可我确实抛弃了这个版本,那么你叫做什么?

2004-11-10 17:26:08 青润
你那叫编写出错。因为你不是在做原型。
 

2004-11-10 17:26:40 Wonder
哈哈,如果程序没错呢?那叫做1.0版本? 呵呵

2004-11-10 17:26:52 青润
是呀,你没有大的错误,必然会沿着开发下去呀。
 

2004-11-10 17:27:27 Wonder
不对,就比如你这个度量,你做下去很多界面就要丢掉,那么你会彻底抛弃重来?

2004-11-10 17:27:30 青润
直到你走不动了,没办法了,需要做一个大的调整的时候,就不得不重新设计,但是,此前的也同样不是原型。因为你没有按照原型的方法来做。
 

2004-11-10 17:27:40 Wonder
这只是选择之一对吧?

2004-11-10 17:28:01 Wonder
还是你一开始就打算继续下去,继续不下去了,就叫做抛弃原型,而不叫做开发失败版本?

2004-11-10 17:28:03 Wonder
呵呵。

2004-11-10 17:28:29 青润
这不是彻底抛弃重来。度量里面我砍掉了一个界面,就是投资估算界面。这属于局部操作,不属于抛弃。实际上,度量中我用的是界面原型法中的渐进方式。
 

2004-11-10 17:28:53 Wonder
那如果按照演示原型方式来作,你画了一堆界面,其实也不知道那些是否真实表达了需求,然后就抛弃掉,继续再画?

2004-11-10 17:29:13 Wonder
是,你用的是渐进方式,但我把这个放在方式上。

2004-11-10 17:29:30 Wonder
但你这么作,其实你自己并不知道是开发,还是演示,还是实用对不对?

2004-11-10 17:29:29 青润
如果是全盘抛弃,那就是抛弃法的思路,每一次都是在考虑全新的,后一次的开发绝对不依赖于前一次的成果。
 

2004-11-10 17:29:40 Wonder
除非开始你就有了决断。

2004-11-10 17:29:50 青润
不,我知道的。如果原型可用,那么,我就会进入开发阶段,如果不可用,我必然要调整。
 

2004-11-10 17:30:03 Wonder
后一次开发绝对不依赖前面的成果,那你前面的事情还有何意义。

2004-11-10 17:30:42 Wonder
问题是你并不能保证你的想法是可行的。在原型阶段,你也不能估计出开发后就不会抛弃

2004-11-10 17:30:53 Wonder
这里头是个预测的问题

2004-11-10 17:31:08 Wonder
而不是靠书本概念来决定的

2004-11-10 17:31:08 青润
但是,前面的已经说明了很多不可操作的方向,不过,抛弃法我也没有用过,可能说的不是很正确。
 

2004-11-10 17:31:46 Wonder
我觉得原型法的说法是有前提的

2004-11-10 17:32:23 青润
我感觉中,抛弃法应该是在你对系统完全没有了解,而又需要快速实现的时候的一种做法。当然,好像对客户方的要求也会有点高。
 

2004-11-10 17:32:40 Wonder
否则我就全部都是开发了,那么被抛弃的就叫做失败或者抛弃的版本,成功的就叫做实用版本。
如果不面向客户,也不作演示,那就没有原型了

2004-11-10 17:33:18 Wonder
那么原型在现实中就只能是演示性原型。
而一旦写了任何功能代码,那就叫做开发版本。呵呵。

2004-11-10 17:33:28 青润
不是的。这样的定义是不正确的。
 

2004-11-10 17:33:49 Wonder
那你怎么定义实用性原型,和开发版本的边界呢? 

2004-11-10 17:34:21 Wonder
这两个概念就混起来了。或者说什么时候算原型,什么时候就算开发版本呢?

2004-11-10 17:34:20 青润
原型的做法中,往往是什么都不考虑的,只要求速度快,让用户看到,不过,这可能也和国内的软件工程管理上的能力比较弱有关,国内只要写出了代码,就认为是有效的,也不管是否符合规范,是否将来可用。所以,国内这方面的确很混乱。
 

2004-11-10 17:35:07 Wonder
原型的做法中,往往是什么都不考虑的,只要求速度快,让用户看到,
那这根本不能算一种科学方法了。如果这个是标准。呵呵。骗过去就行。

2004-11-10 17:35:37 青润
这是一种有效的获取需求的手段,不是在骗。和国内的骗没有直接关系。
 

2004-11-10 17:35:46 Wonder
方法一定是可重复可验证的吧,这才能叫做方法。否则,就是说次次都骗过去,那也算方法,这是有问题的

2004-11-10 17:36:03 Wonder
那还是不说国内的情况了

2004-11-10 17:36:15 Wonder
问题在于这个:
 

2004-11-10 17:36:10 青润
能做原型的人往往都是水平比较高的,或者是经验比较老到的人,而在国内,则是什么东西都敢拿出来骗人。
 

2004-11-10 17:36:16 Wonder
那你怎么定义实用性原型,和开发版本的边界呢? 
 

2004-11-10 17:37:10 Wonder
那比如我们作度量,并没有客户,按照你刚才的说法,你也不能叫做渐进性原型了,你只能叫做验证性版本,或构想性开发版本,

2004-11-10 17:37:10 青润
开发版本是按照公司内规定的开发流程实现的版本。而实用性原型则是在用户处调研需求或者为了快速获取用户需求而实现的版本。
 

2004-11-10 17:37:23 Wonder
因为你也没有给那个人去看对不对。

2004-11-10 17:38:11 Wonder
呵呵,这样就更不对了。
那我们现在动手就在开发,那反而不是开发版本了,呵呵。

2004-11-10 17:38:27 Wonder
因为没有约定公司内规定的开发流程。。。:)

2004-11-10 17:38:45 青润
是的,我没有给客户看。但是,因为我有在客户方工作的经历,所以,我认为一定程度上,我可以来代表客户方进行审核。
 

2004-11-10 17:38:56 Wonder
我觉得其实他们不是按照这个定义的

2004-11-10 17:40:26 Wonder
而是,开始只有演示原型,
如果没有转为开发投入资源的阶段,都算原型。但不知道是演示的,还是实用的。
一旦转入开发阶段投入了资源,则如果实用了原型则,前面就变成了实用性原型,接着立刻产生了第一个开发版本,否则就变成了抛弃型原型,后面重来。
 

2004-11-10 17:40:25 青润
我觉得这个不能吹毛求疵。
 

2004-11-10 17:41:04 Wonder
而我们这种做法,并不算使用了原型法。而是从开始就在开发。

2004-11-10 17:41:46 青润
是的。其实,我本来是想做原型的,但是,后来设计无法做了,才变成了现在这个样子。
 

2004-11-10 17:41:55 青润
也就是从原型直接变成产品。
 

2004-11-10 17:42:32 Wonder
呵呵,那就一致了。

2004-11-10 17:42:38 青润
呵呵。
 

2004-11-10 17:42:47 Wonder
所以原型法有前提,就是客户的参与,如果没有客户的参与,那就不算原型

2004-11-10 17:42:56 Wonder
而直接就是开发。呵呵

2004-11-10 17:43:16 青润
其实不是没有,而是,根据情况而变。
 

2004-11-10 17:43:36 Wonder
其实就是说原型也是在变化的,呵呵

2004-11-10 17:43:58 青润
是的,我的看法一致都是,不变的就是变化。
 

2004-11-10 17:44:13 Wonder
而且说法也不同,可能在商务/投标人员那里叫做原型,如果没有这个划分就无所谓原型不原型了

2004-11-10 17:44:18 青润
根据情况,根据外部环境,根据内部环境和条件,所有的事情都在变化。
 

2004-11-10 17:44:28 Wonder
我是为了确定软件版本状态,你看这么分是否合适。
构想,原型,开发版本,稳定版本,内测版本,公测版本,发行版本,未来研究版本

2004-11-10 17:45:48 Wonder
所以论证下来其实可以不考虑那些衍生的渐进性原型还是抛弃的概念。这个对实用没啥意义,只是人为划分方式。实际上不如划分为演示原型阶段(只捕获需求),然后直接到开发版本,这样比较合适。就是我上面写的

2004-11-10 17:45:53 青润
比较合适。应该没有遗漏的内容。
 

2004-11-10 17:46:53 Wonder
如果开发失败,那么就是失败的0.x版本,而不在说这是原型被我抛弃了。呵呵。因为实际上功能实现已经作了。
说是原型还是说是失败的版本被抛弃,都是人为说法。

2004-11-10 17:47:26 青润
呵呵,这还是有差别的,不过,这里不讨论了。刚才好像已经说清楚了吧?
 

2004-11-10 17:48:19 Wonder
是啊,我看要具体到开发环境里头才能说清楚

2004-11-10 17:48:29 青润
呵呵,那就一致了。我们准备出去吃饭吧。
 

2004-11-10 17:48:47 Wonder
==

2004-11-10 17:48:50 青润
好的。
 

2004-11-10 17:49:04 Wonder
10min

2004-11-10 17:49:05 青润
Ok
 

2004-11-10 17:52:15 Wonder
不过这样,还是可以象你那样划分的。因为
构想,演示性原型,实用性原型,开发版本,稳定版本,内测版本,公测版本,发行版本,未来研究版本
这么写可以涵盖后面的情况,反之则不行。

2004-11-10 17:52:46 Wonder
如果需要,
可以直接,构想-实用性原型,
或构想-开发版本,这就不矛盾了

2004-11-10 17:53:46 青润
不需要这么复杂,演示性原型和实用性原型只要其一就足够了。
 

2004-11-10 17:53:55 青润
本来两者就是并行的。
 

2004-11-10 17:54:22 Wonder
我还是想保留,否则后面的阶段不知道前面就没法定义了

2004-11-10 17:54:39 Wonder
比如定义了原型以后决定不开发了。

2004-11-10 17:54:34 青润
那就做一个并行。
 

2004-11-10 17:55:20 Wonder
如果这种情况就没法叫做实用性原型了

2004-11-10 17:55:31 青润
就叫做原型即可。
 

2004-11-10 17:55:56 青润
前面那样的定义就最合适了。不需要增加分类。
 

2004-11-10 17:56:07 Wonder
呵呵,问题是这种模式受到外在因素影响,作的时候是不知道的。所以还是分开未来标记的时候清晰,是吧?

2004-11-10 17:56:25 Wonder
那也行。

2004-11-10 17:56:21 青润
只要标记出原型,难道还不够么?
 

2004-11-10 17:56:25 青润
是的。
 

2004-11-10 17:57:12 Wonder
嗯,其实是按照时间阶段划分,看要划分多细致了。

2004-11-10 17:57:24 青润
嗯。
 

2004-11-10 17:58:15 Wonder
[图片]

2004-11-10 17:58:30 Wonder
但是到了最后,其实都是层次型的定义。。比如这个版本状态。。

2004-11-10 17:58:39 青润
哦。
 

2004-11-10 17:58:54 青润
这是bugzero上的界面么?
 

2004-11-10 17:59:06 Wonder
走吧

2004-11-10 17:59:05 青润
好的。

本文地址:http://com.8s8s.com/it/it34082.htm