《游戏开发成本WORD》由会员分享，可在线阅读，更多相关《游戏开发成本WORD（18页珍藏版）》请在金锄头文库上搜索。
1、在下最近和一朋友交谈，无意间谈起了游戏成本。虽然在下木有接触过游戏开发的成本计算，但是软件行业的成本计算应该基本是相同的。 本文将从以下几个方面讨论如何避免增加成本的风险。1。开发过程。2。生命周期。3。支出收入汇总及改良。4。优化团队。大概以上4点出发，目的就是减少因自身产生的不必要的成本的增加，比如：1。初期需求不确定，后期修改需求，导致反工从而大幅度提高成本。2。团队的资源浪费。技术工人能做的事，却让本科生做。3。其他。再看看必要的成本增加：1。不确认需求，使用原型模型生命周期确认需求分析。2。大规模开发过程中，不断的跌代。（增量模型）3。超大规模系统开发，螺旋模型。4。工程以外支出（请
2、客，送礼，贿赂等）5。其他（员工工资等）1。开发过程：初步需求分析-可行性分析-需求分析-概要设计-详细设计-写代码-测试-提交1。1过程注释：开发都离不开客户，所以什么都得以客户需求为准。排第一的过程必定是初步需求分析。用户的要求不一定都是需求，必定有很多用户不知道当前的技术是否能实现他所要求的，在这一阶段。从自己公司情况评估可行性，如果不行，请重新考虑是否接受这个项目或者砍掉这个不合理的需求。（规避这阶段的风险的进入）以上步奏完成后，才开始真正的需求分析。如果用户的水平很高，可以很快的确认需求就是他所要求的。这个阶段会省很多的成本。如果用户的水平不高，获得的部分需求很模糊，那就得按增量模型
3、。（必要的成本增加）如果用户的水平很低，基本获得不了需求，按照原型模型制作针对每一个要求的功能的模型并让用户确认。并且反复此过程，直到用户需求收集完毕。此过程中的模型将被抛弃。（再次规避这阶段风险的进入）。概要设计阶段：根据需求分析，画出UML图，完成基本的架构设定。参与需求分析人员的人员和系统分析师共同完成此阶段。（规避此阶段因为需求分析人员所描述和系统分析师理解的概念不同而进入的风险）详细设计：根据需求分析，概要设计的UML图。完成设定相关类的选定以及功能的实现。参与需求分析人员和系统分析师以及程序人员共同完成。（规避了因程序人员理解和概要设计描述不同进入的风险）代码阶段：这个阶段最大的风
4、险就是人员的流失和调动，尽量避免过多的程序组的调动。而这个阶段必须拥有规范的编写方式，以及文档记录。减少因人员丢失引起的问题。这个阶段的风险在于，人员调动，文档记录是否规范。测试阶段：测试顾名思义，就是找出问题。而不是测试系统多么完善。天下没有完善的系统，当交付一个项目的时候只有祈祷用户使用的时候不会涉及未测试的部分。此阶段风险，在于确认需求测试，单元测试，以及集成测试等测试后。必定还有更多的测试用例未被测试。（此风险不可避免，这个也是项目需要后续开发的原因）测试应该尽量多的测试用例，当然，时间也得多。但是测试阶段必定不能跳过。大概描述第一个完了。暂时出去。一会回来继续-华丽分割线-2。生命周
5、期。(此部分基本引自各种书籍）这里有必要讲一下传统的软件工程开发方法-生命周期方法学（这里引自某书）软件工程采用的传统方法是生命周期方法学。软件工程强调使用生命周期方法学和各种结构分析及结构设计技术，它们是在20世纪70年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。软件工程采用的生命周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干
6、个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。采用生命周期方法学开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束，如果检查通不过，则必须进行必要的返工，并且返工后还要再经过审查。审
7、查的一条主要标准就是每个阶段都应该交出“最新的”，即和所开发的软件完全一致的高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置及文档交付使用。文档是通信的工具，它们清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生命周期的下一阶段之前，必须补足这些遗漏的细节，保证文档的正确和完整。瀑布模型：（引自互连网）按照传统的生命周期方法学开发软件，各阶段的工作自顶向下从抽象到具体顺序进行，就好像奔流不息的瀑布，一泻千里，总是从高处依次流到低处。因此，传统的生命周期方法
8、学可以用瀑布模型(Waterfallmodel)来模拟。按照传统的瀑布模型来开发软件，有如下几个特点，这些特点隐含在软件生命周期各阶段的观点和指导思想中，是比具体任务更根本的东西。(1)阶段间具有顺序性和依赖性这个特点有两重含义：第一，必须等前一阶段的工作完成之后，才能开始后一阶段的工作；第二，前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。(2)推迟实现的观点清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。瀑
9、布模型在编码之前设置了系统分析与系统设计阶段，这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。(3)质量保证的观点软件工程的基本目标是优质、高产。保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法：第一，每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。第二，每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。及时审查是保证软件质量、降低软件成本的重要措施。瀑布模型这种模型本质上是一种线性顺序模型，因此存在着较明显的缺点，各
10、阶段之间存在着严格的顺序性和依赖性，特别强调预先定义需求的重要性，在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步的实现这些需求。但是实际项目很少遵循着这种线性顺序进行的。虽然瀑布模型也允许迭代，但这种改变往往对项目开发带来混乱。在系统建立之前很难只依靠分析就确定出一套完整、准确、一致、有效的用户需求，这种预先定义需求的方法更不能适应用户需求的不断变化的情况。1.需求是可变的某些应用软件的需求与外部环境、公司经营策略或经营内容等密切相关，因此需求是随时变化的。2.需求是模糊的对于大多数更常使用的应用系统，例如管理信息系统，其需求往往很难预先准确的指定，也
11、就是说，预先定义需求的策略所做出的假设，只对某些软件成立，对多数软件并不成立。许多用户对他们的需求最初只是模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部需求，显然是不切实际的。人们为了充实和细化他们的初步设想，通常需要经过在某个能运行的系统上实践的过程。3.用户和开发者难于沟通大型软件的开发需要系统分析员、软件工程师、程序员、用户、领域专家等各类人员的协调配合。然而大多数用户和领域专家不熟悉计算机和软件技术，软件开发人员也往往不熟悉用户的专业领域，开发人员和用户之间很难做到完全沟通和相互理解，在需求分析阶段做出的用户需求常常是不完整、不正确的。传统的瀑布模型很难适应需求可变、模
12、糊不定的软件系统的开发，而且在开发过程中，用户很难参与进去，只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程，缺乏灵活性，不适应实际的开发过程。-再次华丽分割线-2。快速原型模型1.原型原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。2.快速原型思想的产生由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的，在获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需
13、求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。又把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展。即先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。3.快速原型的原理快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。4.原型运用方式由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。(1)抛弃策略是将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。探索型和实验型就是采用此策略的。(2)附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、人员素质、可供支持的原型开发工具和技术等，这要根据实际情况的特点来决定。有兴趣的可以查http:/
