精华内容
下载资源
问答
  • 2004-11-10 16:57:06 Wonder原型分为多少种? 2004-11-10 16:58:08 青润实用性原型、演示性原型,主要是这两类。在这上面还衍生出了一些其它的...没有见到过很详细的介绍原型法的资料。 2004-11-10 16:58:56 Wonder我需

    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 青润
    好的。

    展开全文
  • 而在这个过程中,提出了许多不同软件开发模型,典型有:瀑布式,快速原型法,以及迭代式开发等。 瀑布式模型 是由W.W.Royce在1970年最初提出软件开发模型,在瀑布模型中,开发被认为是按照需求分析,...

    自从1968年提出“软件工程”概念以来,软件开发领域对于借鉴传统工程的原则、方法,以提高质量、降低成本的探索就从未停止过。而在这个过程中,提出了许多不同的软件开发模型,典型的有:瀑布式,快速原型法,以及迭代式开发等。

    • 瀑布式模型

    是由W.W.Royce在1970年最初提出的软件开发模型,在瀑布模型中,开发被认为是按照需求分析,设计,实现,测试 (确认), 集成,和维护顺序的进行。

    • 快速原型法
      快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。
    • 迭代式开发

    在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。

    不同的开发模型,对于设计阶段的工作要求也不尽相同。相对来说,瀑布式模型中对于设计文档的粒度要求得最细,而快速原型法对于设计的要求一般来说比较弱,迭代式开发在每一阶段中的设计文档工作量都相对较少,但在软件开发完成后,最终的设计文档完善程度要比快速原型法的好。

    软件设计的总体思路

    软件设计的本质就是针对软件的需求,建立模型,通过将模型映射为软件,来解决实际问题。因此软件设计需要解决的核心问题是建立合适的模型,使得能够开发出满足用户需求的软件产品,并具有以下特性:

    • 灵活性(Flexibility)
    • 有效性(Efficiency)
    • 可靠性(Reliability)
    • 可理解性(Understandability)
    • 维护性(Maintainability)
    • 重用性(Reuse-ability)
    • 适应性(Adaptability)
    • 可移植性(Portability)
    • 可追踪性(Traceability)
    • 互操作性(Interoperability)

    因此,软件设计并没有一套放之四海而皆准的方法和模板,需要我们的设计开发人员在软件的设计开发过程中针对软件项目的特点进行沟通和协调,整理出对软件项目团队的行之有效的方式,进行软件的设计。并保障软件设计文档的一致性,完整性和可理解性。

    谁来进行软件设计

    在我们开发人员中,有很多人这样理解:“软件设计文档就是软件架构师和设计人员的事情”,其实不然。设计文档是整个软件开发团队的产出,其中有些设计文档由架构师或者设计人员给出,有些文档由开发人员给出。这并没有一定的区分。

    最佳实践

    我们经常听到这样的话:

    • “设计文档没有用,是用来糊弄客户和管理层的文档”;
    • “用来写设计文档的时间,我的开发早就做完了”;
    • “项目紧张,没有时间做设计”;

    这些言论,并不是正确的观念,根据软件项目的实际情况,软件开发设计团队可以约定设计文档的详细程度。项目团队需要保障设计文档的完整性和一致性,在项目进度紧张的情况下,软件设计文档可以更初略一些;在项目时间充裕的情况下,相关文档可以更为详尽。但是在项目开发过程中,需要软件设计开发团队对于设计文档有共同的理解。

    设计文档分类与使用

    通常来说,作为软件项目,我们需要有这几类文档

    • 需求说明文档
    • 功能设计文档
    • 系统架构说明书
    • 模块概要设计文档
    • 模块详细设计文档

    就像我之前说到的,在某个软件团队,对于以上的文档的要求是可以完全不同的,在简单项目中,可能所有类型的文档放在一个文档中进行说明;在复杂项目中,每一类文档可能都要写几个文档;而在最极端的情况下,可能每一类文档都能装订成几册。因此,在我们软件设计和开发人员心目中需要明确的是:文档并不是我们进行设计的目标,也不是我们设计过程中额外的工作。

      软件设计文档是我们在软件设计开发过程中形成的,用来在软件设计开发团队内部以及与各干系人之间进行沟通的文档,这些文档记录了软件项目中的各种知识,方案的思路、以及各种决策意见

    下面我们就软件设计开发过程中必须要完成的工作进行梳理,而我们需要注意到,这些需要完成的工作,在不同的开发流程模型的指导下可能有不同的时间要求,而我们需要关注的是在这个阶段内需要完成的工作,以及这个阶段内我们需要沟通的人员。

    需求分析

    需求分析是我们进行任何一个软件项目设计开发过程中都必须要完成的工作。

    这个工作通常与客户一起完成。在不同的项目中,这个“客户”可能来自真正的购买产品的用户,使用系统的用户,也有可能来自团队的某个人员,如产品经理等。软件设计开发团队的参与成员根据项目的不同规模,则参与的人员也有所不同。原则上,设计开发人员参与的时间点越早,对于需求的理解和把握会更好。这个阶段,通常需要软件架构师参与其中。从资源优化的角度来说,开发人员不必参与需求分析,但需要理解需求。

    需求分析的结果通常我们需要使用需求说明文档来描述,目前主流的需求描述方法包括:用户例图、用户故事等方式。这些方式有所不同的侧重,其核心思想就是描述清楚用户的使用场景。但无论采取何种方式,进行需求的描述,需求说明需要明确以下几点:

    • 所需要开发的软件系统边界
    • 系统所有的相关及使用人员角色
    • 系统关键的使用场景
    • 系统规模、性能要求以及部署方式等非功能性需求

    功能设计

    功能设计与需求分析差不多同时在开展,在很多软件项目中,对于功能设计不是特别重视。但对于某些软件项目而言,这是一个相当重要的工作。对于主要是用户界面的软件项目来说,功能设计可以看作是画出原型界面,描述使用场景,获得用户认可的过程。而对于没有界面的软件项目来说,则功能设计与需求分析的区分更为模糊。

    参与的人员与需求分析的参与人员类似,架构师更侧重于参与此类工作,并给与一些实现层面的判断和取舍。

    功能设计需要明确的核心是:

    • 系统的行为

    系统架构设计

    系统架构设计是一个非常依赖于经验的设计过程。需要根据软件项目的特定功能需求和非功能性需求进行取舍,最终获得一个满足各方要求的系统架构。系统架构的不同,将很大程度上决定系统开发和维护是否能够较为容易的适应需求变化,以及适应业务规模扩张。

    架构设计工作中,用户参与程度很低。软件开发团队中的需求人员参与程度很低,但团队中的所有核心设计和开发人员都应该参与其中,并达成一致意见。

    架构设计的主要成果,是将系统的不同视图予以呈现,并使之落实到开发中:

    • 系统开发视图及技术路线选择
    • 系统逻辑视图
    • 系统部署视图
    • 系统模块视图
    • 系统的领域模型

    在软件开发过程中,系统的架构不是一成不变的,随着设计人员和开发人员对于系统的理解不断深入,系统的架构也会发生演化。在软件项目中,架构设计是开发团队沟通的统一语言,设计文档必须要随着系统的变化进行更新,保障开发团队对于系统的理解和沟通的一致性。

    模块/子系统概要设计

    模块/子系统的概要设计,由架构师参与,核心设计和开发人员负责的方式进行。
    在概要设计工作中,我们需要在架构确定的开发路线的指导下,完成模块功能实现的关键设计工作。在概要设计阶段,需要关注于模块的核心功能和难点进行设计。这个过程中更多推荐的采用UML来进行概要设计,需要进行:

    • 模块实现机制设计
    • 模块接口设计
    • 关键类设计
    • 画出时序图
    • 交互图等。

    模块详细设计

    在瀑布式开发模型中,模块的详细设计会要求比较严格,将所有类进行详细设计。据我所知,除了一些对于系统健壮性要求非常严格的软件项目,如国防项目,金融项目还要求有详细设计文档之外。其他的项目大多采用其他方式来处理这样的工作,如自动化测试等。

    综上所述,软件设计文档作为软件开发团队的沟通、理解、知识共享的手段,具有非常重要的意义。而根据软件团队的规模,对于文档上承载的信息详细程度可以有不同程度的要求。我们软件团队对于*如何使用设计文档有一个统一的理解,并坚持更新设计文档*,这就是软件设计的最佳实践!

    软件设计所需要的知识与技能

      • UML 统一建模语言
      • 软件工程
      • 面向对象的编程 OOP
      • 操作系统
      • 数据库原理
      • 设计模式
      • 沟通能力
    展开全文
  • 一、概念  为了提高效率,我们经常用复制方式,所以,做从头一点点(初始化一个新对象),结果就像直接使用(行时状态)。  前几天我做演讲ppt,...原型模式便是当中之中一个。  原型模式(Pro...

    一、概念

      为了提高效率,我们经常用复制的方式,所以,做从头一点点(初始化一个新的对象),结果就像直接使用(行时的状态)。

      前几天我做演讲的ppt,就有偷懒之嫌~ 把大家的优秀博客。截图然后copy到ppt其中,这样免去了又一次构思这一环节,高质量(大家的功劳 O(∩_∩)O~)。高效率。

      设计模式中也不乏类似功能的模式。

    原型模式便是当中之中的一个。

      原型模式(Prototype):用原型实例指定创建对象的种类。而且通过拷贝这些原型创建新的对象。不须要知道不论什么创建的细节。


    二、UML图

    客户(Client)对象:使用原型对象的客户程序

    抽象原型(Prototype)对象:声明了克隆自身。且详细原型对象必须实现的接口(假设是深复制,必须有实现clone的规定)。

    详细类型(ConcretePrototype)对象:从抽象原型派生而来。是客户程序使用的对象,即被复制的对象。此角色须要实现抽象原型角色所要求的接口,实现一个克隆自身的操作。


    三、实例解析

      学习了设计模式之后,小M最终有了一份工作(满18了,木有非法使用童工。。)。为了获得很多其它推销自己的机会。她设计了一张自己的名片,包括的信息有:姓名 性别 年龄 电话。

    可是一张名片送人之后。就再也没有了,所以她通过原型模式又给自己copy了几张。


       //client代码
        class Program
        {
            static void Main(string[] args)
            {
                ConcreteBussinessCard bc = new ConcreteBussinessCard("小M");
                bc.SetPersonalInfo("女","18","12345678901");
    
                //克隆类ConcreteBussinessCard的对象bc就能得到新的实例bc1
                ConcreteBussinessCard bc1 = (ConcreteBussinessCard)bc.Clone();
                bc1.SetPersonalInfo("女", "18", "12345678901");
    
                bc.Display();
                bc1.Display();
    
                Console.Read();
              
               
            }
        }
    
    
        //抽象名片类
        abstract class BussinessCard
        {
            //定义名片包括信息:姓名,性别,年龄。电话号码为私有变量
            private string name;      
            private string sex;
            private string age;  
            private string phoneNumber; 
    
    
            //构造函数
            public BussinessCard(string name)
            {
                this.name = name;           
            }
    
            //设置个人信息
            public void SetPersonalInfo(string sex, string age,string phoneNumber)
            {
                this.sex = sex;
                this.age = age;
                this.phoneNumber = phoneNumber;
            }
    
            //显示
            public void Display()
            {
                Console.WriteLine("姓名:{0}  性别:{1}  年龄:{2}",name ,sex ,age );
                Console.WriteLine(" 电话:{0}",phoneNumber );
    
            }
    
            //关键是这里有一个Clone方法
            public abstract BussinessCard Clone();
            
        }
    
    
    
    
        //详细名片类
        class ConcreteBussinessCard : BussinessCard
        {
            public ConcreteBussinessCard(string name)
                : base(name)
            { }
    
    
            public override BussinessCard Clone()
            {
                return (BussinessCard)this.MemberwiseClone();//创建当前的浅表副本。

    } } }


    执行结果:



    四、深复制和浅复制

      背景:MemberwiseClone()方法是这样,假设字段是值类型的,则对该字段运行逐位复制,假设字段是引用类型,则复制引用但不复制引用的对象;因此。原始对象及其复本引用同一对象。



    浅复制:被复制对象的全部变量都含有与原来的对象同样的值,而全部的对其它对象的引用都仍然指向原来的对象。

    深复制:把引用对象的变量指向复制过的新对象,而不是原有的被引用的对象。


    五、总结

      原型模式可以简化代码。优化设计。让我们摆脱了手工抄写的时代。代码相同可以推动社会进步!


    Ps:对深复制和浅复制的理解还非常浅,看了一些大牛博客。这不是很清楚,我们期待着教练!

    版权声明:本文博主原创文章,博客,未经同意不得转载。

    展开全文
  • 执行策划负责在实际工作中将整个游戏具体玩进行落实,同时输出详细策划书,很多游戏细节和乐趣都是在执行策划这一步加入。 文案策划负责设计将整个游戏世界观、故事背景以及对话等,通过文本表现出来,...

    游戏策划的职位分工,主要分为主策划、系统策划、执行策划、文案策划、数值策划以及场景策划等几个职位。

    其中,主策划负责整个游戏的整体规划,同时担任着整个策划组的工作分配和进度审核的任务。

    系统策划更偏向于游戏架构和核心系统的设计,是决定一个游戏游戏机制的角色。

    执行策划负责在实际工作中将整个游戏的具体玩法进行落实,同时输出详细的策划书,很多游戏的细节和乐趣都是在执行策划这一步加入的。

    文案策划负责设计将整个游戏的世界观、故事背景以及对话等,通过文本表现出来,尤其是一些故事向的游戏或者3A大作,一个强大的文案策划团队是不可或缺的。

    数值策划更多的是负责有关战斗系统部分的策划,可以是真正的战斗系统,也可以是伪战斗系统(如俄罗斯方块向下掉落的速度),一个优秀的数值系统是吸引高玩的重要因素。

    场景策划则要负责一个具体场景的设计,包括风格,布局,玩法,npc怪物道具等。

    游戏团队的组成此处从略,具体参考思维导图对应部分。
    在这里插入图片描述
    游戏创意的来源,主要分为空想、利用现有的娱乐资源(如电影、网页游戏、小说)和利用现有的游戏体系(改良借鉴,或者进行多种优秀思想的融合)。同时还要进行创意的收集,比如将一些灵感和临时的想法记录下来,以备后用。

    在编写游戏概念设计文档的时候,要将下面的几个要素都规定清楚,这样才方便进行下一步的活动。不过这份文档更偏向有游戏整体的设计,比如游戏游玩的方式是什么、获胜的条件是什么、角色是谁、有哪些场景以及有哪些视图等等。当然最重要的一点就是要考虑清楚,玩家为什么想玩你的游戏,你的游戏最吸引玩家的地方是什么,是操作感,是画面,还是故事情节等。

    游戏原型设计是先设计一个demo的demo,让全体开发人员对接下来要做的事情有个概念。其应该使用最简单的形式将游戏的核心表述清楚,同时最好能辅助以说明图片或者试玩demo。
    在这里插入图片描述

    展开全文
  • ES5类,原型,继承

    2019-01-12 20:48:48
    类是 面向对象程序设计语言中一个概念。类(Class)实际上是对某种类型对象定义变量和方法的原型。 它表示对现实生活中一类具有共同特征事物抽象,类构造函数是类实例化后对象本地方法和属性, 而类中...
  • JS中prototype 原型

    千次阅读 2011-12-08 14:41:27
    JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。  JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属性本身又是一...
  • js原型

    千次阅读 2014-03-04 12:13:56
    JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。  JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属性本身又是一个...
  • prototype 原型

    2012-06-11 15:22:27
    JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。  JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属性本身又是一...
  • 本文来自网易云社区作者:林玮园雷火游戏部 网站组基本概念:一、什么叫原型图?用线条、图形描绘出产品/专题框架,即为原型,也可称线框图。原型输出可根据质量,大致分为低保真、中保真、高保真原型图。编辑...
  • prototype 原型

    2016-04-26 10:59:07
    JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。 JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属性本身又是一个...
  • prototype 原型

    2009-10-08 09:44:00
    JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。 JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属性本身又是一个...
  • JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。 JavaScript 的所有function类型的对象都有一个prototype属性。这个prototyp
  • JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。 <br />  JavaScript 的所有function类型的对象都有一个prototype属性。这个prototype...
  • 每个原型的设计和实施大约需要一到两个星期,并测试原始游戏玩机制和/或概念原型和Phaser均使用JavaScript编程,因此它们可以在大多数现代Web浏览器中运行。 看到 移相器Github页面: :
  • JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。 JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属
  • JavaScript—继承(下) ...JavaScript中 prototype概念恰如其分地反映了这个词内含。JavaScript所有function类型对象都有一个prototype属性。既然prototype是对象"原型",那么由该函数构造出来对象应该都...
  • JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。  JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属性本身又是一...
  • JavaScript中的prototype概念恰如其分地反映了这个词的内含,我们不能将其理解为C++的prototype那种预先声明的概念。 JavaScript的所有function类型的对象都有一个prototype属性。这个prototype属性本...

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 170
精华内容 68
关键字:

原型法的概念