附录L-2 Beta测试报告.doc

测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。 [1] 它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。

附录L-1 Beta测试协议.doc

Beta测试是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求，确保所开发的软件产品符合用户的各项要求。 　　Beta测试由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。

附录K-1 系统测试计划.doc

测试计划Testing plan，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。 [1] 它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。

附录J-1 实现与测试计划.doc

通过测试，达到以下目标： 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。 产品规定的操作和系统运行稳定。 Bug数和缺陷率控制在可接收的范围之内，遗留BUG一般不超过所有BUG的10%。

附录H-2 技术预研报告.doc

预研项目不同于一般的新产品开发项目，它所瞄准的通常是不确定或者比较遥远的市场。由于难以预料究竟什么样的产品或技术会在将来的市场竞争中胜出，公司需要根据自己的情况和对未来市场的基本预测，早早地开始新技术或产品预研。由于先发制人的优势所带来的高额回报，可以补偿这类项目的前期回报，因此许多公司都非常乐于或者提倡这类项目的开发。像我司每年开展的新技术展示、工业设计的ACP发布便属于此种有组织，大规模的预研项目。

附录H-1 技术预研计划.doc

技术预研计划

附录G-1 用户需求说明书.doc

用户需求分析是指在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。 例如采用Rational的Rose工具进行需求的建模分析。如果使用工具进行建模分析，对需求分析人员的要求比较高。需求定义过程中通常会出现的问题有内容失实、遗漏、含糊不清和前后描述不一致。

附录F-2 需求变更控制报告.doc

需求变更控制是指正确判断内在或外在原因的变更所带来的影响，并且调整开发过程以控制和适应这些变化，是需求管理的主要工作之一。 　　需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序地进行。变更控制给项目风险承担者提供了正式的需求变更处理机制，通过这些处理机制，决策人就可以准确地分析需求变更给整个项目所带来的影响和波动，从而对需求变更进行判断以决定是否接受、拒绝或者延迟，最终确保项目开发范围可控。

附录F-1 需求跟踪报告.doc

　需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。

附录E-2 风险管理报告.doc

检查表是按照系统工程分析方法，在对一个系统进行科学分析的基础上，找出各种可能存在的风险因素，然后以提问的方式将这些风险因素列成的表格。可按团队、设备、时期等类别，由风险管理专业人员、生产技术人员和工人共同参与编制。编制程序如下：（1)将整个项目看作一个系统，再把系统分成若干个子系统；（2)找出各个子系统存在的风险因素；（3)针对各个项目风险因素，查找有关控制标准或规范；（4)根据项目风险因素的大小及重要程度依次列出问题清单。