游戏开发成本Word文件下载.docx
《游戏开发成本Word文件下载.docx》由会员分享，可在线阅读，更多相关《游戏开发成本Word文件下载.docx（13页珍藏版）》请在冰豆网上搜索。
这个阶段会省很多的成本。
如果用户的水平不高，获得的部分需求很模糊，那就得按增量模型。
（必要的成本增加）
如果用户的水平很低，基本获得不了需求，按照原型模型制作针对每一个要求的功能的模型并让用户确认。
并且反复此过程，直到用户需求收集完毕。
此过程中的模型将被抛弃。
（再次规避这阶段风险的进入）。
概要设计阶段：
根据需求分析，画出UML图，完成基本的架构设定。
参与需求分析人员的人员和系统分析师共同完成此阶段。
（规避此阶段因为需求分析人员所描述和系统分析师理解的概念不同而进入的风险）
详细设计：
根据需求分析，概要设计的UML图。
完成设定相关类的选定以及功能的实现。
参与需求分析人员和系统分析师以及程序人员共同完成。
（规避了因程序人员理解和概要设计描述不同进入的风险）
代码阶段：
这个阶段最大的风险就是人员的流失和调动，尽量避免过多的程序组的调动。
而这个阶段必须拥有规范的编写方式，以及文档记录。
减少因人员丢失引起的问题。
这个阶段的风险在于，人员调动，文档记录是否规范。
测试阶段：
测试顾名思义，就是找出问题。
而不是测试系统多么完善。
天下没有完善的系统，当交付一个项目的时候只有祈祷用户使用的时候不会涉及未测试的部分。
此阶段风险，在于确认需求测试，单元测试，以及集成测试等测试后。
必定还有更多的测试用例未被测试。
（此风险不可避免，这个也是项目需要后续开发的原因）
测试应该尽量多的测试用例，当然，时间也得多。
但是测试阶段必定不能跳过。
大概描述第一个完了。
。
暂时出去。
一会回来继续
--------------------华丽分割线-------------------
（此部分基本引自各种书籍）
这里有必要讲一下传统的软件工程开发方法----生命周期方法学（这里引自某书）
软件工程采用的传统方法是生命周期方法学。
软件工程强调使用生命周期方法学和各种结构分析及结构设计技术，它们是在20世纪70年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。
人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。
软件工程采用的生命周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。
采用生命周期方法学开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。
前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。
每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。
在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束，如果检查通不过，则必须进行必要的返工，并且返工后还要再经过审查。
审查的一条主要标准就是每个阶段都应该交出“最新的”，即和所开发的软件完全一致的高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置及文档交付使用。
文档是通信的工具，它们清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。
此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生命周期的下一阶段之前，必须补足这些遗漏的细节，保证文档的正确和完整。
瀑布模型：
（引自互连网）
按照传统的生命周期方法学开发软件，各阶段的工作自顶向下从抽象到具体顺序进行，就好像奔流不息的瀑布，一泻千里，总是从高处依次流到低处。
因此，传统的生命周期方法学可以用瀑布模型（Waterfallmodel）来模拟。
按照传统的瀑布模型来开发软件，有如下几个特点，这些特点隐含在软件生命周期各阶段的观点和指导思想中，是比具体任务更根本的东西。
（1）
阶段间具有顺序性和依赖性
这个特点有两重含义：
第一，必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
第二，前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
（2）
推迟实现的观点
清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。
瀑布模型在编码之前设置了系统分析与系统设计阶段，这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。
（3）
质量保证的观点
软件工程的基本目标是优质、高产。
保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法：
第一，每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。
第二，每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
及时审查是保证软件质量、降低软件成本的重要措施。
瀑布模型这种模型本质上是一种线性顺序模型，因此存在着较明显的缺点，各阶段之间存在着严格的顺序性和依赖性，特别强调预先定义需求的重要性，在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步的实现这些需求。
但是实际项目很少遵循着这种线性顺序进行的。
虽然瀑布模型也允许迭代，但这种改变往往对项目开发带来混乱。
在系统建立之前很难只依靠分析就确定出一套完整、准确、一致、有效的用户需求，这种预先定义需求的方法更不能适应用户需求的不断变化的情况。
1.需求是可变的
某些应用软件的需求与外部环境、公司经营策略或经营内容等密切相关，因此需求是随时变化的。
2.需求是模糊的
对于大多数更常使用的应用系统，例如管理信息系统，其需求往往很难预先准确的指定，也就是说，预先定义需求的策略所做出的假设，只对某些软件成立，对多数软件并不成立。
许多用户对他们的需求最初只是模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部需求，显然是不切实际的。
人们为了充实和细化他们的初步设想，通常需要经过在某个能运行的系统上实践的过程。
3.用户和开发者难于沟通
大型软件的开发需要系统分析员、软件工程师、程序员、用户、领域专家等各类人员的协调配合。
然而大多数用户和领域专家不熟悉计算机和软件技术，软件开发人员也往往不熟悉用户的专业领域，开发人员和用户之间很难做到完全沟通和相互理解，在需求分析阶段做出的用户需求常常是不完整、不正确的。
传统的瀑布模型很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中，用户很难参与进去，只有到开发结束才能看到整个软件系统。
这种理想的、线性的开发过程，缺乏灵活性，不适应实际的开发过程。
-----------再次华丽分割线--------
快速原型模型
1.原型
原型是指模拟某种产品的原始模型，在其他产业中经常使用。
软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。
2.快速原型思想的产生
由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的，在获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。
又把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展。
即先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。
3.快速原型的原理
快速原型是利用原型辅助软件开发的一种新思想。
经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。
4.原型运用方式
由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。
（1）抛弃策略是将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。
探索型和实验型就是采用此策略的。
（2）附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。
采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、人员素质、可供支持的原型开发工具和技术等，这要根据实际情况的特点来决定。
有兴趣的可以查
--------------华丽分割线--------------
增量模型
1.原型的作用
（1）为软件系统提供明确的需求说明，当用户要求含糊不清、不完全、不稳定时，通过原型执行、评价，使用户要求明确。
（2）原型可作为新颖设计思想的思想工具，也可作为高风险开发的安全因素，从而证实设计的可行性。
（3）原型模型支持软件产品的演化，对开发过程中的问题和错误具有应付变化的机制。
（4）原型模型鼓励用户参与开发过程，参与原型的运用和评价，能充分地与开发者协调一致。
2.使用原型的建议
能够使用原型的情况：
（1）开发周期很长的项目，通过原型开发来缩短开发周期。
（2）系统的使用可能变化较大，不能相对稳定，而原型模型具有适应变化的机制。
（3）用户对系统的需求较为模糊，对某种要求缺乏信心。
（4）开发者对系统的某种设计方案的实现无信心或无十分把握。
上述这些情况均适合于使用原型模型来开发。
3.原型的优点
（1）可及早为用户提供有用的产品。
（2）可及早发现问题，随时纠正错误。
（3）减少技术、应用风险，缩短开发实际，减少费用，提高生产率。
（4）通过实际运行原型，提供直接评价系统的方法，促使用户主动参与开发活动，加强了信息反馈，促进各类人员的协调，减少误解，适应需求的变化，能有效提高系统质量。
4.存在问题
（1）缺乏丰富而强有力的软件工具和开发环境。
（2）缺乏有效的管理机制，还未建立起自己的开发标准。
（3）对设计人员水平及开发环境要求较高。
（4）在多次重复改变原型的过程中，程序员会感到厌倦。
（5）系统的易变性对测试有一定影响，难于做到彻底测试，更新文档较为困难。
过程图：
---------------------------------------
5.螺旋模型
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1）
制定计划：
确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）
风险分析：
分析评估所选方案，考虑如何识别和消除风险；
（3）
实施工程：
实施软件开发和验证；
（4）
客户评估：
评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
但是，螺旋模型也有一定的限制条件，具体如下：
螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
------------------------------
6。
RUP
RUP（Rational
Unified
Process，统一软件开发过程，统一软件过程）是一个面向对象且基于网络的程序开发方法论。
根据Rational（Rational
Rose和统一建模语言的开发者）的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。
RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPEN
Process都是理解性的软件工程工具--把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内
一、六大经验
迭代式开发,管理需求,基于组件的体系结构,可视化建模,验证软件质量,控制软件变更。
二、统一软件开发过程RUP的二维开发模型
三、统一软件开发过程RUP核心概念
角色：
描述某个人或者一个小组的行为与职责。
RUP预先定义了很多角色。
活动：
是一个有明确目的的独立工作单元。
工件：
是活动生成、创建或修改的一段信息。
四、统一软件开发过程RUP裁剪
RUP是一个通用的过程模板，包含了很多开发指南、制品、开发过程所涉及到的角色说明，由于它非常庞大所以对具体的开发机构和项目，用RUP时还要做裁剪，也就是要对RUP进行配置。
RUP就像一个元过程，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。
RUP裁剪可以分为以下几步：
1）
确定本项目需要哪些工作流。
RUP的9个核心工作流并不总是需要的，可以取舍。
2）
确定每个工作流需要哪些制品。
3）
确定4个阶段之间如何演进。
确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。
4）
确定每个阶段内的迭代计划。
规划RUP的4个阶段中每次迭代开发的内容。
5）
规划工作流内部结构。
工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。
最后规划工作流的内部结构，通常用活动图的形式给出。
五、开发过程中的各个阶段和里程碑
1．
初始阶段 2．
细化阶段
3．
构造阶段
4．
交付阶段
六、统一软件开发过程RUP的核心工作流（Core
Workflows）
商业建模（Business
Modeling）
2．
需求（Requirements）
分析和设计（Analysis
&
Design）
实现（Implementation）
5．
测试（Test）
6．
部署（Deployment）
7．
配置和变更管理（Configuration
Change
Management）
8．
项目管理（Project
9．
环境（Environment）
七、RUP的迭代开发模式
与传统的瀑布模型相比较，迭代过程具有以下优点：
降低了在一个增量上的开支风险。
如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
降低了产品无法按照既定进度进入市场的风险。
通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
加快了整个开发工作的进度。
因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。
因此，迭代过程这种模式使适应需求的变化会更容易些
八、统一软件开发过程RUP的十大要素
1.
开发前景
2.
达成计划
3.
标识和减小风险
4.
分配和跟踪任务。
5.
检查商业理由
6.
设计组件构架
7.
对产品进行增量式的构建和测试
8.
验证和评价结果
9.
管理和控制变化
10.
提供用户支持
有兴趣的可以直接查阅
------------------------第2部分完-------------
（此部分数据仅仅作为引用，不具备参考价值）
这个属于软件开发管理的范围。
但是说起管理就太多了。
而老板们关心的是钱。
所以抓出来特别说说。
过程问题：
软件开发成本管理过程中的主要问题
项目成本预算和估算的准确度差。
由于客户的需求不断变化，使得工作内容和工作量不断变化。
一旦发生变化，项目经理就追加项目预算，预算频频变更，等到项目结束时，实际成本和初始计划偏离很大。
此外，项目预算往往会走两个极端：
过粗和过细。
预算过粗会使项目费用的随意性较大，准确度降低；
预算过细会使项目控制的内容过多，弹性差，变化不灵活，管理成本加大。
缺乏对软件成本事先估计的有效控制。
在开发初期，对成本不够关心，忽略对成本的控制，只有在项目进行到后期，实际远离计划出现偏差的时候，才进行成本控制，这样往往导致项目超出预算。
缺乏成本绩效的分析和跟踪。
传统的项目成本管理中，将预算和实际进行数值对比，但很少有将预算、实际成本和工作量进度联系起来，考虑实际成本和工作量是否匹配的问题。
成本管理方法的改进
目前常用的软件项目管理工具都侧重于某一方面的功能，如微软的
Project2000侧重管理、规划任务，并在项目执行过程中跟踪这些任务，偏向于进度安排与跟踪控制；
RUP侧重于用户需求的描述；
PVCS侧重于软件变更管理。
这些软件项目管理工具都在不断的完善其功能，虽然也有成本管理的功能，但总的来说大多数都不能用来进行软件成本估计，缺乏事先成本控制，不能和估计数据自动化协调，不能自动化地利用历史数据库中的数据。
当前的项目管理工具并不能满足成本管理的需要。
针对以上成本管理过程中出现的问题，以及目前软件项目管理工具的不足，文章提出了一种改进的管理方法，将进度和成本联系起来考虑使工作量和实际成本匹配的方法。
并且结合已有的成本估算方法，同时将过程数据库引入到软件项目管理中，给出成本管理系统的原型设计。
系统采用先进的估算方法解决了成本估算准确度差的问题，工作量和实际成本匹配的方法进行成本的绩效分析和跟踪使得项目成本能够控制在预算范围之内。
2.1系统总体设计
虽然目前已有不少项目管理软件，但一般只是管理软件进度和跟踪监督，和软件估算是项目独立的，而且目前还没有成型的软件项目成本管理软件，我们以
为指南，研究软件开发过程中的特殊性，结合现有的软件成本估算技术和一般行业的项目管理技术，以进度、人员、成本，变更为中心，提出了软件成本管理的具体实施方案。
并以此为基础对系统的功能进行分析和设计。
2.2
系统功能设计
（1）成本估算是项目成本管理的一个非常重要的部分，精确的软件成本估算是进行有效的软件管理的一个必不可少的组成部分。
常用的软件估算方法有：
算法模型法、专家判定法、类比估算法等，这些方法各有优缺点。
本文采用文献[2]中提到的方法，即将各方法结合起来，互相取长补短，由层次分析法得到各种估算法的权重，再由权重合成法得到估算成本。
它可以提高软件成本估算的精确度。
定义
设f1，f2，┅，fm为m个不同模型所得的估算值，wi（i=1，2，┅，m）为第i个模型的权重，则
f＝
且
即为权重组合估算模型。
假设用COCOMO模型[3]估算成本为MM1，TDEV1，用Delphi技术估算成本为MM2，TDEV2，用类比估算法估算成本为MM3，TDEV3，则由权重组合估算得：
MM＝w1MM1＋w2MM2＋w3MM3
TDEV＝w1
TDEV1＋w2
TDEV2＋w3
TDEV3
这里MM是软件开发需要的人月数，TDEV是软件开发周期。
（2）预算变更管理可以记录每一次资源和成本的变化，保持完整的有注释的历史记录。
（3）成本基准计划是成本控制得标准。
即使最好的项目经理采用最优的成本估算方法，也 不可能使预算和实际成本完全一致。
因此，项目成本估算应该预留总成本的5%－10%作为不可预见的成本，用于应急项目成本，在成本估算和预算之上。
成本控制的基准是项目管理人员根据项目的具体情况确定允许的偏差范围。
在一个项目的进行中，成本基准计划并非一成不变的，而是随着用户的需求变化，项目的变更请求基准计划可能会得到不断的校正。
（4）进度计划分为控制计划和执行计划，允许用户实时查询进度计划以及实际进度状态。
成本估算通常与工作量联系起来考虑，成本的跟踪控制过程也是进度计划的执行与调整的过程。
（5）成本控制是根据成本基准计划来控制项目预算的变化，成本控制过程的主要输出是修正的成本估算、更新预算、纠正行动、完工估算和取得的教训。
成本绩效分析和跟踪将预算和实际进行数值对比，将预算成本、实际成本和工作量进度联系起来，考虑实际成本和工作量是否匹配。
系统解决实际成本和工作量匹配的方案如图2。
如果实际成本和实际进度不匹配则重新调整计划，采取必要的措施防止项目成本失去控制。
（6）过程数据库存放项目的成本管理过程的历史数据，它由已完成项目的数据构成。
这些数据可用于成本估算，成本计划，绩效分析等方面。
它除了为进行新的项目成本计划提供依据，也可以为进行中的项目提供实时的过程数据。
在项目初始基准计划制定时期，以过去类似项目的历史过程度量数据为经验，制定基准计划，执行计划。
将本次项目开发执行过程的过程度量数据存入数据库，作为下一次开发计划制定的经验数据。
这样，计划的制定越来越接近实际。
----------------------------------------------
第3部分完。
4：
具体请见《人月神话》外科手术团队举例。
升级会员 