游戏开发的过程.docx
《游戏开发的过程.docx》由会员分享，可在线阅读，更多相关《游戏开发的过程.docx（18页珍藏版）》请在冰点文库上搜索。
游戏开发的过程
游戏开发过程
摘要：
什么是软件工程2
软件工程（SoftWareEngineering）框架可概括为：
目标、过程和原则。
（1）软件工程目标：
生产具有正确性、可用性以及开销合宜产品。
正确性指软件产品达到预期功能程度。
可用性指软件基本结构、实现及文档为用户可用程度。
开销合宜是指软件开发、运行整个开销满足用户要求程度。
这些目标实现不论在理论上还是在实践中均存在很多待解决问题，它们形成了对过程、过程模型及工程方法选取约束。
（2）软件工程过程：
生产一个最终能满足需求且达到工程目标软件产品所需要步骤。
软件工程过程主要包括开发过程、运作过程、维护过程。
它们覆盖了需求、设计、实现、确认以及维护等活动。
需求活动包括问题分析和需求分析。
问题分析获取需求定义，又称软件需求规约。
需求分析生成功能规约。
设计活动一般包括概要设计和详细设计。
概要设计建立整个软件系统结构，包括子系统、模块以及相关层次说明、每一模块接口定义。
详细设计产生程序员可用模块说明，包括每一模块中数据结构说明及加工描述。
实现活动把设计结果转换为可执行程序代码。
确认活动贯穿于整个开发过程，实现完成后确认，保证最终产品满足用户要求。
维护活动包括使用过程中扩充、修改及完善。
伴随以上过程，还有管理过程、支持过程、培训过程等。
（3）软件工程原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循原则。
1软件开发流程概要
需求分析——概要设计——详细设计——编码——单元测试——集成测试——系统测试
——维护
2需求调研
①调研用户领域组织结构、岗位设置和职责定义，从功能上区分有多少个子系统，划分系统大致范围，明确系统目标。
②调研每个子系统所需工作流程、功能及处理规则，收集单据、报表和账本等原始资料，分析物流、资金流和信息流三者关系，以及如何用数据流来表示这三者关系。
③对调研内容事先准备，针对不同管理层次用户询问不同问题，列出问题清单。
将操作层、管理层和决策层需求既联系，又区分开来，形成一个金字塔，使下层满足上层需求。
④对及用户沟通情况及时总结归纳，整理调研结果，找出新疑点，初步构成需求基线。
⑤若基线符合要求，则需求分析完毕；反之返回到第1步或第2或第3步。
如此循环多次，直到需要分析使双方满意为止。
3可行性分析和需求分析
可行性分析是要决定“做还是不做”。
需求分析是要决定“做什么，不做什么”。
3.1可行性分析
3.1.1经济
经济可行性分析主要包括：
“成本——收益”分析和“短期——长远利益”分析。
3.1.1.1成本——收益
（1）办公室房租。
（￥）
（2）办公用品，如桌、椅、书柜、照明电器、空调等。
（￥）
（3）计算机、打印机、网络等硬件设备。
（￥）
（4）电话、传真等通讯设备以及通讯费用。
（￥）
（5）资料费。
（￥）
（6）办公消耗，如水电费、打印复印费等。
（￥）
（7）软件开发人员及行政人员工资。
（￥）
（8）购买系统软件费用，如买操作系统、数据库、软件开发工具等。
有些老板买盗版系统软件，却按市场价算成本，可从美国佬那里赚一笔。
（￥）
（9）做市场调查、可行性分析、需求分析交际费用。
（￥）
（10）公司人员培训费用。
（￥）
（11）产品宣传费用。
如果用Internet作宣传，则要考虑建设Web站点费用。
（￥）
（12）如果客户是政府部门，还要充分考虑用于吃喝玩乐、行贿费用。
（￥）
（13）如果公司风水不好，会有很多莫名其妙管理费。
每戳一个红艳艳公章都要化一把钞票。
（￥）
3.1.1.2短期——长远利益
人们喜欢吃着碗里、看着锅里，还想着别人家里。
短期利益和长远利益兼得是人们梦寐以求事。
在商业上，这等好事可不会轻易降临。
短期利益容易把握，风险较低。
但收益有限，做是项目。
长远利益难以把握，风险较大。
但收益可能巨大，做是企业。
3.1.2技术
技术可行性分析至少要考虑以下几方面因素：
（1）在给定时间内能否实现需求说明中功能。
（2）软件质量如何？
主要考虑在网络、硬件、市场竞争等上面分析。
（3）软件生产率如何？
主要是开发周期、移植性、维护、扩展方面考虑。
技术可行性分析可以简单地表述为：
做得了吗？
做得好吗？
做得快吗？
3.1.3社会环境
社会环境可行性至少包括两种因素：
市场及政策。
3.1.3.1市场
市场又分为未成熟市场、成熟市场和将要消亡市场。
涉足未成熟市场要冒很大风险，要尽可能准确地估计潜在市场有多大？
自己能占多少份额？
多长时间能实现？
挤进成熟市场，虽然风险不高，但油水也不多。
如果供大于求。
收入稳定
将要消亡市场就别进去了。
如DOS时代编程现在不可能有人去做了。
3.1.3.2政策
政策对软件公司生存及发展影响非常大。
需要考虑：
国家网络法律发展、及对项目限制，是否有鼓励机制，新网络技术等先进科技引进等（如3G时代什么时候到来，对我们项目会有什么影响等。
）
3.1.4人因数
技术人员水平如何，时间安排是否可以到位，特殊情况（如病假等）等对项目开发进度和质量影响。
如何合理安排人手，对各个计划（小功能块）开发时限分析等，对于项目开发是非常重要。
3.2需求分析
有几种原因使需求分析变得困难：
（1）客户说不清楚需求；
（2）需求自身经常变动；（3）分析人员或客户理解有误。
3.2.1客户说不清楚需求
也可以理解为市场人员和初级策划要给出整个软件开发目，消费人群，市场等内容。
3.2.2需求自身经常变动
首先先接受“需求会变动”这个事实，免得在需求变动时惊慌失措。
明白“需求会变动”这个道理后，在进行需求分析时就要留点神：
（1）尽可能地分析清楚哪些是稳定需求，哪些是易变需求。
以便在进行系统设计时，将软件核心建筑在稳定需求上，否则将会吃尽苦头。
（2）在文档中一定要说清楚“做什么”和“不做什么”。
3.2.3分析人员或客户理解有误
不同分析人员可能有不同理解。
如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。
所以在具体项目开发过程中，程序员和策划还有市场要随时沟通，不断交流。
3.2.4业务需求
业务需求说明了提供给客户和产品开发商新系统最初利益。
不同产品可能会有不同侧重点。
本部分描述了你为什么要从事此项项目开发，以及它将给开发者和购卖者带来利益。
3.2.4.1背景
在这一部分，总结新产品理论基础，并提供关于产品开发历史背景或形势一般性描述。
3.2.4.2业务机遇
描述现存市场机遇或正在解决业务问题。
描述商品竞争市场和信息系统将运用环境。
包括对现存产品一个简要相对评价和解决方案，并指出所建议产品为什么具有吸引力和它们所能带来竞争优势。
认识到目前只能使用该产品才能解决一些问题，并描述产品是怎样顺应市场趋势和战略目标。
3.2.4.3业务目标
用一个定量和可测量合理方法总结产品所带来重要商业利润。
关于给客户带来价值在后面阐述，这里仅把重点放在给业务价值上。
这些目标及收入预算或节省开支有关，并影响到投资分析和最终产品交付日期。
3.2.4.4客户或市场需求
描述一些典型客户需求，包括不满足现在市场上产品或信息系统需求。
提出客户目前所遇到问题在新产品中将可能（或不可能）出现阐述，提供客户怎样使用产品例子。
确定了产品所能运行软、硬件平台。
定义了较高层次关键接口或性能要求，但避免设计或实现细节。
把这些要求写到列表中，可以反过来跟踪调查特殊用户和功能需求。
3.2.4.5提供给客户价值
确定产品给客户带来价值，并指明产品怎样满足客户需要。
可以用下列言辞表达产品带给客户价值：
1.提高生产效率，减少返工；
2.节省开支；
3.业务过程流水线化；
4.先前人工劳动自动化；
5.符合相关标准和规则；
6.及目前应用产品相比较，提高了可用性或减少了失效程度。
3.2.4.6业务风险
总结开发（或不开发）该产品有关主要业务风险，例如市场竞争、时间问题、用户接受能力、实现问题或对业务可能带来消极影响。
预测风险严重性，指明你所能采取减轻风险措施。
3.2.4.7项目视图
文档中这一部分为系统建立了一个长远项目视图，它将指明业务目标。
这一项目视图为在软件开发生存期中做出决策提供了相关环境背景。
这部分不包括详细功能需求和项目计划信息。
3.2.4.7.1项目视图陈述
编写一个总结长远目标和有关开发新产品目简要项目视图陈述。
项目视图陈述将考虑权衡有不同需求客户看法。
它可能有点理想化，但必须以现有或所期待客户市场企业框架。
组织战略方向和资源局限性为基础。
3.2.4.7.2主要特征
包括新产品将提供主要特性和用户性能列表。
强调是区别于以往产品和竞争产品特性。
可以从用户需求和功能需求中得到这些特性。
包括拥有功能，用户对象，优势等内容。
3.2.4.7.3假设和依赖环境
在构思项目和编写项目视图和范围文档时，要记录所做出任何假设。
通常一方所持假设应及另一方不同。
如果你把它们都记录下来，并加以评论，就能对项目内部隐含基本假设达成共识。
（该产品市场定位，和依赖环境）
3.2.4.8范围和局限性
项目范围定义了所提出解决方案和概念和适用领域，而局限性则指出产品所不包括某些性能。
如果一般客户所提出需求超出项目范围时就应当拒绝它，除非这些需求是很有益。
记录这些需求以及拒绝它们原因，以待查。
3.2.4.8.1首次发行范围
总结首次发行产品所具有性能。
描述了产品质量特性，这些特性使产品可以为不同客户群提供预期成果。
应当避免将想到每一个特性都包括到1.0版本产品中去。
开发者应把重点放在能提供最大价值、花花费最合理开发费用及普及率最高产品上。
3.2.4.8.2随后发行范围
如果你想象一个周期性产品演变过程，就要指明哪一个主要特性开发将被延期，并期待随后版本发行日期。
3.2.4.8.3局限性和专用性
明确定义包括和不包括特性和功能界线是处理范围设定和客户期望一个途径。
列出风险承担者们期望而你却不打算把它包括到产品中特性和功能。
3.2.4.9业务环境
这一部分总结了一些项目业务问题。
3.2.4.10客户概貌
客户概述明确了这一产品不同类型客户一些本质特点，以及目标市场部门和在这些部门中不同客户特征。
对于每一种客户类型，概述要包括：
Ø各种客户类型将从产品中获得主要益处；
Ø它们对产品所持态度；
Ø感兴趣关键产品特性；
Ø哪一类型客户能成功使用；
Ø必须适应任何客户限制。
3.2.4.11项目优先级
一旦明确建立项目优先级，风险承担者和项目参及者就能把精力集中在一系列共同目标上。
达到这一目一个途径是考虑软件项目五个方面：
性能、质量、计划、成本和人员。
3.2.4.12产品成功因素
明确产品成功是如何定义和测量，并指明对产品成功有巨大影响几个因素。
不仅要包括组织直接控制范围内事务，还要包括我部素。
如果可能，可建立测量标准，用于评价是否达到业务目标，如：
市场股票、销售量及收入、客户满意度、交易处理量和准确度。
4系统设计（策划及程序员完成）
系统设计是新系统物理设计阶段。
根据系统分析阶段所确定新系统逻辑模型、功能要求，在用户提供环境条件下，设计出一个能在计算机网络环境上实施方案，即建立新系统物理模型。
这个阶段任务是设计软件系统模块层次结构，设计数据库结构以及设计模块控制流程，其目是明确软件系统"如何做"。
这个阶段又分两个步骤：
概要设计和详细设计。
概要设计解决软件系统模块划分和模块层次机构以及数据库设计；详细设计解决每个模块控制流程，内部算法和数据结构设计。
这个阶段结束，要交付概要设计说明书和设计说明，也可以合并在一起，称为设计说明书。
4.1架构设计
架构设计也被认为是体系结构设计，重点在于将系统分层并产生层次内模块、阐明模块之间关系。
主要工作是根据架构分析和设计思想产生系统架构图，并对架构图进行描述，说明分层原因、层次职责，并根据架构图绘制系统物理部署图，描述系统部署体系。
根据架构图进行模块划分并阐明模块划分理由，绘制模块物理图以及模块依赖图。
体系结构是软件系统中最本质东西：
（1）体系结构是对复杂事物一种抽象。
良好体系结构是普遍适用，它可以高效地处理多种多样个体需求。
（2）体系结构在一定时间内保持稳定。
只有在稳定环境下，人们才能干点事情，社会才能发展。
如果当需求发生变化时，程序员不得不去修改软件体系结构，那么这个软件系统设计是失败。
良好体系结构意味着普适、高效和稳定。
4.2概要设计
概要设计主要任务是把需求分析得到数据流图（DFD）转换为软件结构和数据结构。
设计软件结构具体任务是：
将一个复杂系统按功能进行模块划分、建立模块层次结构及调用关系、确定模块间接口及人机界面等。
数据结构设计包括数据特征描述、确定数据结构特性、以及数据库设计。
显然，总体设计建立是目标系统逻辑模型，及计算机无关。
概要设计重点在于将模块分解为对象并阐明对象之间关系，引用架构设计说明书中模块图，并阐述对于模块进行设计大致思路。
主要工作是根据该模块职责对模块进行概要设计（分解模块为对象、描述对象职责以及声明对象之间接口），绘制模块对象图、对象间依赖图以及模块主要功能序列图，分别加以描述并相应描述模块异常处理方法。
如果需要并描述数据视图。
在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做也大部分是和编码同步进行，或者在编码之后。
因此，对大部分公司来说，概要设计文档是唯一设计文档，对后面开发、测试、实施、维护工作起到关键性影响。
4.2.1概要设计任务
制定规范：
代码体系、接口规约、命名规则。
这是项目小组今后共同作战基础，有了开发规范和程序模块之间和项目成员彼此之间接口规则、方式方法，大家就有了共同工作语言、共同工作平台，使整个软件开发工作可以协调有序地进行。
总体结构设计：
功能（加工）－>模块：
每个功能用那些模块实现，保证每个功能都有相应模块来实现；
模块层次结构：
某个角度软件框架视图；
模块间调用关系：
模块间接口总体描述；
模块间接口：
传递信息及其结构；
处理方式设计：
满足功能和性能算法
用户界面设计；
数据结构设计：
详细数据结构：
表、索引、文件；
算法相关逻辑数据结构及其操作；
上述操作程序模块说明（在前台？
在后台？
用视图？
用过程？
······）
接口控制表数据结构和使用规则
其他性能设计。
4.2.2概要设计写什么
结构化软件设计说明书结构
任务：
目标、环境、需求、局限；
总体设计：
处理流程、总体结构及模块、功能及模块关系；
接口设计：
总体说明外部用户、软、硬件接口；内部模块间接口（注：
接口≈系统界面）
数据结构：
逻辑结构、物理结构，及程序结构关系；
模块设计：
每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、及其它模块接口，及其它系统或硬件接口），处在什么逻辑位置、物理位置；
运行设计：
运行模块组合、控制、时间；
出错设计：
出错信息、处错处理；
其他设计：
保密、维护；
4.2.3概要设计模板
1引言
1.1编写目
说明编写这份概要设计说明书目，指出预期读者。
1.2背景
说明：
a.待开发软件系统名称；
b.列出此项目任务提出者、开发者、用户以及将运行该软件计算站（中心）。
1.3定义
列出本文件中用到专门术语定义和外文首字母组词原词组。
1.4参考资料
列出有关参考文件，如：
a.本项目经核准计划任务书或合同，上级机关批文；
b.属于本项目其他已发表文件；
c.本文件中各处引用文件、资料，包括所要用到软件开发标准。
列出这些文件标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料来源。
（序号资料名文件编号发表日期出版单位）
2总体设计
2.1需求规定
说明对本系统主要输入输出项目、处理功能性能要求（可以参考需求说明书）
2.1.1功能描述
2.1.2性能要求
2.2运行环境
简要地说明对本系统运行环境（包括硬件环境和支持环境）规定（可以参考需求说明书）
2.3基本设计概念和处理流程
说明本系统基本设计概念和处理流程，尽量使用图表形式。
注：
可以使用word绘制流程图（示意图），也可以使用专业MSVisio或者RationalRose绘制
2.4结构
用一览表及框图或者树状图形式说明本系统系统元素（各层模块、子程序、公用程序等）划分，扼要说明每个系统元素标识符和功能，分层次地给出各元素之间控制及被控制关系。
2.5功能需求及程序关系
本条用一张如下矩阵图说明各项功能需求实现是处于哪个模块中：
模块1
模块2
……
模块n
功能需求1
√
功能需求2
√
……
功能需求n
√
√
如：
模块1
模块2
……
模块n
用户名、密码验证
√
修改用户个人信息
√
2.6人工处理过程
说明在本软件系统工作过程中不得不包含人工处理过程（如果有话）。
2.7尚未问决问题
说明在概要设计过程中尚未解决、而设计者认为在系统完成之前必须解决各个问题。
3接口设计
3.1用户接口
说明将向用户提供命令和它们语法结构，以及软件回答信息。
3.2外部接口（硬件接口）
说明本系统同外界所有接口安排，包括软件及硬件之间接口、本系统及各支持软件之间接口关系，比如需要从外界系统接收哪些数据，或者需要输出哪些数据给外部系统等
3.3内部接口（软件接口）
说明本系统之内各个系统元素之间接口安排（可暂时先省去）
4运行设计
4.1运行模块组合
说明对系统施加不同外界运行控制时所引起各种不同运行模块组合，说明每种运行所历经内部模块和支持软件。
模块集合运行条件支持软件
4.2运行控制
说明每一种外界运行控制方式方法和操作步骤。
运行名称控制方法操作步骤
4.3运行时间
说明每种运行模块组合将占用各种资源时间。
运行名称所占资源时间
5系统数据结构设计
5.1逻辑结构设计要点
给出本系统内所使用每个数据结构名称、标识符以及它们之中每个数据项、记录、文卷和系标识、定义、长度及它们之间层次或表格相互关系。
5.2物理结构设计要点
给出本系统内所使用每个数据结构中每个数据项存储要求，访问方法、存取单位、存取物理关系（索引、设备、存储区域）、设计考虑和保密条件。
补充说明：
5.1和5.2可以合并为列出数据库中所有表设计结构
5.3数据结构及程序关系
说明各个数据结构（表）及访问这些数据结构模块关系：
模块1
模块2
……
模块n
数据库表1
√
数据库表2
√
……
数据库表n
√
√
6系统出错处理设计
6.1出错信息
用一览表方式说明每种可能出错或故障情况出现时，系统输出信息形式、含意及处理方法。
出错情况提示信息发生条件解决办法
6.2补救措施
说明故障出现后可能采取变通措施，可能包括：
a.后备技术说明准备采用后备技术，当原始系统数据万一丢失时启用副本建立和启动技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体一种后备技术；
b.降效技术说明准备采用后备技术，使用另一个效率稍低系统或方法来求得所需结果某些部分，例如一个自动系统降效技术可以是手工操作和数据人工记录；
c.恢复及再启动技术说明将使用恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行方法。
6.3系统维护设计
说明为了系统维护方便而在程序内部设计中做出安排，包括在程序中专门安排用于系统检查及维护检测点和专用模块。
各个程序之间对应关系
4.3详细设计
详细设计重点在于对每个模块进行实现，将模块对象分解为属性和方法，并阐述如何实现。
主要工作视根据模块概要设计详细描述对于模块内对象实现，包括对象职责、属性、方法、对象内功能流程图、对象关联类、对象异常。
（需要绘制主要为类图）
详细设计目标有两个：
实现模块功能算法要逻辑上正确和算法描述要简明易懂。
主要任务：
1．为每个模块确定采用算法，选择某种适当工具表达算法过程，写出模块详细过程性描述；
2．确定每一模块使用数据结构；
3．确定模块接口细节，包括对系统外部接口和用户界面，对系统内部其它模块接口，以及模块输入数据、输出数据及局部数据全部细节。
在详细设计结束时，应该把上述结果写入详细设计说明书，并且通过复审形成正式文档。
交付给下一阶段（编码阶段）工作依据。
4．要为每一个模块设计出一组测试用例，以便在编码阶段对模块代码（即程序）进行预定测试，模块测试用例是软件测试计划重要组成部分，通常应包括输入数据，期望输出等内容。
5编码（主要为程序员完成）
对具体软件编写及实现。
软件编码是将上一阶段详细设计得到处理过程描述转换为基于某种计算机语言程序，即源程序代码。
需注意根据项目应用领域选择适当编程语言、编程软硬件环境以及编码程序设计风格等事项
6测试（主要为程序员完成）
“白盒测试”是指开发人员从程序内部对上述内容进行测试，而“黑盒测试”是指独立测试人员从程序外部对上述内容进行测试。
6.1单元测试
对单个模块进行测试
单元测试是在软件开发过程中要进行最低级别测试活动，在单元测试活动中，软件独立单元将在及程序其他部分相隔离情况下进行测试。
6.2集成测试
对整个软件或工程进行测试
集成测试，也叫组装测试或联合测试。
在单元测试基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。
程序在某些局部反映不出来问题，在全局上很可能暴露出来，影响功能实现。
6.2.1集成测试方法
集成测试应该考虑以下问题：
1、在把各个模块连接起来时候，穿越模块接口数据是否会丢失；
2、各个子功能组合起来，能否达到预期要求父功能；
3、一个模块功能是否会对另一个模块功能产生不利影响；
4、全局数据结构是否有问题；
5、单个模块误差积累起来，是否会放大，从而达到不可接受程度。
6.2.2集成测试实施
集成测试是一种正规测试过程，必须精心计划，并及单元测试完成时间协调起来。
在制定测试计划时，应考虑如下因素：
1、是采用何种系统组装方法来进行组装测试；
2、组装测试过程中连接各个模块顺序；
3、模块代码编制和测试进度是否及组装测试顺序一致
4、测试过程中是否需要专门硬件设备；
6.2.3集成测试完成标准
怎样判定集成测试过程完成了,可按以下几个方面检查:
1、成功地执行了测试计划中规定所有集成测试；
2、修正了所发现错误；
3、测试结果通过了专门小组评审。
7系统测试
系统测试是将已经确认软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统各种组装测试和确认测试，其目是通过及系统需求相比较，发现所开发系统及用户需求不符或矛盾地方。
8维护（主要为程序员完成）
软件维护一般划分为主要三类：
纠错性维护（Correctivemaintenance）、适应性维护（Adaptivemaintenance）和完善性维护（Perfectivemaintenance）：
（1）纠错性维护。
由于前期测试不可能揭露软件系统中所有替在错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误过程称为纠错性维护。
（2）适应性维护。
由于新硬件设备不断推出，操作系统和编译系统也
升级会员 