文档介绍：
: .
在下最近和一朋友交谈，无意间谈起了游戏成本。虽然在下木有接触过游戏开发的成本计算，但是软件行业的成本计算应该基本是相同的。
本文将从以下几个方面讨论如何避免增加成本的风险。
1。开发过程。
2。生命周期。
3。支出收入汇总及改良。
4。优化团队。
大概以上4点出发，目的就是减少因自身产生的不必要的成本的增加，比如：
1。初期需求不确定，后期修改需求，导致反工从而大幅度提高成本。
2。团队的资源浪费。技术工人能做的事，却让本科生做。
3。其他。
再看看必要的成本增加：
1。不确认需求，使用原型模型生命周期确认需求分析。
2。大规模开发过程中，不断的跌代。（增量模型）
3。超大规模系统开发，螺旋模型。
4。工程以外支出（请客，送礼，***等）
5。其他（员工工资等）
1。开发过程：
初步需求分析-》可行性分析-》需求分析-》概要设计-》详细设计-》写代码-》测试-》提交
1。1过程注释：
开发都离不开客户，所以什么都得以客户需求为准。排第一的过程必定是初步需求分析。
用户的要求不一定都是需求，必定有很多用户不知道当前的技术是否能实现他所要求的，在这一阶段。从自己公司情况评估可行性，如果不行，请重新考虑是否接受这个项目或者砍掉这个不合理的需求。（规避这阶段的风险的进入）
以上步奏完成后，才开始真正的需求分析。
如果用户的水平很高，可以很快的确认需求就是他所要求的。这个阶段会省很多的成本。
如果用户的水平不高，获得的部分需求很模糊，那就得按增量模型。（必要的成本增加）
如果用户的水平很低，基本获得不了需求，按照原型模型制作针对每一个要求的功能的模型并让用户确认。并且反复此过程，直到用户需求收集完毕。此过程中的模型将被抛弃。（再次规避这阶段风险的进入）。
概要设计阶段：
根据需求分析，画出UML图，完成基本的架构设定。参与需求分析人员的人员和系统分析师共同完成此阶段。（规避此阶段因为需求分析人员所描述和系统分析师理解的概念不同而进入的风险）
详细设计：
根据需求分析，概要设计的UML图。完成设定相关类的选定以及功能的实现。参与需求分析人员和系统分析师以及程序人员共同完成。（规避了因程序人员理解和概要设计描述不同进入的风险）
代码阶段：
这个阶段最大的风险就是人员的流失和调动，尽量避免过多的程序组的调动。
而这个阶段必须拥有规范的编写方式，以及文档记录。减少因人员丢失引起的问题。
这个阶段的风险在于，人员调动，文档记录是否规范。
测试阶段：
测试顾名思义，就是找出问题。而不是测试系统多么完善。天下没有完善的系统，当交付一个项目的时候只有祈祷用户使用的时候不会涉及未测试的部分。
此阶段风险，在于确认需求测试，单元测试，以及集成测试等测试后。必定还有更多的测试用例未被测试。（此风险不可避免，这个也是项目需要后续开发的原因）
测试应该尽量多的测试用例，当然，时间也得多。但是测试阶段必定不能跳过。
大概描述第一个完了。。暂时出去。。一会回来继续
--------------------华丽分割线-------------------
2。生命周期。(此部分基本引自各种书籍）
这里有必要讲一下传统的软件工程开发方法----生命周期方法学（这里引自某书）
软件工程采用的传统方法是生命周期方法学。软件工程强调使用生命周期方法学和各种结构分析及结构设计技术，它们是在20世纪70年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。
    软件工程采用的生命周期方法学就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。采用生命周期方法学开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。
    在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束，如果检查通不过，则必须