下载文档原格式
1简介 (2)1.1目的 (2)1.2适用范围 (2)1.3术语表 (2)1.4参考资料 (2)1.5职责描述 (2)2配置管理活动 (3)2.1软件资源与硬件资源 (3)2.2标识配置项 (3)2.2.1配置项标识规则 (3)2.2.2配置项名称格式说明 (4)2.2.3配置项 (4)2.3项目基线管理 (4)2.3.1基线列表 (5)2.3.2基线建立流程 (5)2.3.3基线的变更控制 (6)2.4发布管理 (7)2.5配置库管理 (7)2.5.1各类库结构 (7)2.5.2库的权限设置 (8)2.5.3库的备份与恢复 (8)2.6配置状态的记录和报告 (8)2.7 配置审计 (8)2.8人员安排与时间安排 (9)3数据资料管理计划 (9)1简介1.1目的木计划是用来指导项目配置管理作业的过程与步骤，以便全而地管理、保存软件生命周期各个配置项，监控各配置项的状态，让小组所有成员能及时了解软件基线的状态和内容，从而实现对软件过程的控制，持续改进软件流程，保证软件产品质量、降低风险，实现项目规划的所有需求，同时提高开发团队的工作效率、降低软件开发成木。
1.2适用范围木项目中纳入配置管理的活动：项目管理文档(如项目计划、配置计划等)、项目技术文档(需求规格说明书、概要设计等)、源程序及模块文档、基线、产品、用户文档、项目工具。
1.3术语表1.4参考资料无1.5职责描述表2-12配置管理活动配置活动的目的是向项目组每一个人传达在木项目中如何进行配置。
参见《配置管理过程文件》。
2.1软件资源与硬件资源2.2标识配置项2.2.1配置项标识规则项目级的配置项是指由于项目实施而产生的记录。
为了便于查询、搜索今后各项目的文档及版本，下面将专门制订一套约定，统一、规范项目的命名格式。
凡进入项目级配置管理库下的工作产品都应依照下列命名约定进行。
1）举例示例1,系统项目计划的配置标识：--------------------------------------------- 系统---------------------------------------------------- 北京驰波名气通数据服务有限公司2.2.2配置项名称格式说明1） 配置库中配置项命名格式的顺序是根据产出物所产生的文档先后次序 来命名的，例如：01-项目配置管理计划；02-功能配置审计报告。
详细设计书目录1 引言 (1)1.1编写目的 (1)1.2项目背景 (1)1.3预期读者 (2)1.4参考文献 (2)2任务概述 (2)2.1目标 (2)2.2运行环境 (3)2.3需求概述 (3)2.4条件与限制 (4)3总体设计 (4)3.1功能模块分析 (4)3.2总体结构及模块结构 (8)3.3详细功能模块设计 (8)3.4数据库设计 (13)4接口设计 (20)4.1 外部接口设计 (20)4.2软件接口 (35)4.3硬件接口 (35)4.4内部接口设计 (35)5运行设计 (35)5.1运行模块的组合 (35)5.2运行控制 (35)5.3运行时间 (36)6出错处理设计 (36)6.1出错输出信息 (36)6.2出错处理对策 (36)7安全保密设计 (36)8维护设计 (37)1 引言1.1编写目的本设计方案对云计算中心管控平台软件系统的总体设计与实现作详细说明。
用于记录系统在技术层面上的实施过程，以需求说明作为设计的根本出发点，作为产品实现、功能要求和控制的依据。
为开发人员指明设计方向，便于其在最短的时间内开发出功能最齐全的软件。
1.2项目背景随着网络技术的逐步成熟，网络服务的不断增加，互联网行业已经进入了一个高速发展期。
传统的需求设计，开发测试，上线部署的软件开发模式已经很难满足这些企业快速的发展需求。
而于此同时另一种新的按需付费的软硬件交付模式越来越受到许多企业青睐。
为此，我们开发出一套用于管理云计算中心订单和服务收费的软件系统——鼎驰云计算中心计费管理系统，用于云计算中心管理人员对用户申请的订单进行审核、审批管理，对用户租用云计算中心的资源和服务产生的费用进行计费，并形成管理需要的报表，旨在为相关管理工作提供一个科学、便捷的软件平台，提高管理水平，提高工作效率。
开发软件名称：云计算中心管控平台软件项目开发者：江苏鼎驰电子科技有限公司11.3预期读者本说明书的预期读者是项目的开发人员，测试人员和维护人员。
配置状态报告
第页共页
配置状态报告填写说明
配置状态报告按规定时间，以项目为单位由配置管理员汇总并提交。
配置状态报告由多页组成，因此应编制页码，每一页都应有表头。
1)项目名称：以受控库为单位的项目名称。
2)序号：从1开始顺序排列，次页连续排列。
3)配置项名称：配置项的中文名称。
对一个配置项的若干个分项（卷），每
个分项都作为一个配置项管理。
4)配置标识：包括版本号的配置项标识。
5)时间：本配置项最近一次状态变更的时间，用CCYY-MM-DD表示。
6)状态：配置项的现行状态。
状态分为三类：
●建立：表示本配置项是首次入库从未进行过任何变更；
●修改：表示本配置项正在修改过程中；
●重建：表示本配置项经变更后从新入库。
变更后从新入库可能会出现
多次，一律用“重建”表示，用版本号区分。
备注：其他要说明的信息。
CM计划1 前言1.1 目的本计划是XXX项目计划的组成部分，它规定了在信贷管理系统项目中如何开展配置管理工作，以便在项目的整个生存周期中，建立和维护工作产品的完整性和一致性。
1.2术语定义和缩写词CCB（Configuration Control Board）：配置控制委员会Baseline：基线，是开发规程中标识出的里程碑所交付的一个或多个配置项，它有以下三个特征：•已经通过正式的评审和批准；•作为项目扩展和产品升级的基础；•其变更必须遵循《配置管理规程》的约定。
1.3 参考文献《配置管理规程》项目计划初稿2 角色、职责与培训2.1 角色与职责2.2 CCB组成3 配置管理活动3.1 基线和配置项的标识本项目的配置项和基线的名称和编号参见《配置项状态报告》。
项目初期，需要确定项目的配置项并对其进行标识。
当新增或修改配置项时，同样需要对配置项进行标识。
本项目的配置项和基线的标识详见《配置项标识和状态列表》（基线的变更标识依照《配置管理规程》执行），该表包括配置项和基线清单及预计创建时间。
3.2 配置库结构和权限3.2.1 配置管理库描述本配置管理库作为CVS中的一个独立的源代码仓库（Repository），分成四个物理上互相独立的存储空间：产品空间、基线空间、组工作空间和个人空间，每个空间作为一个独立的目录（用module实现）。
产品空间属于产品库，基线空间、组工作空间的内容均属于受控库，个人空间的内容属于开发库。
产品空间：存放提交给用户的产品；基线空间：存放所有基线内容。
组工作空间：存放经过评审的文档和所有不放入基线库的工作产品，个人空间：项目组成员存放个人任何信息，文档的开发和修改均在个人空间进行。
从个人空间向组工作空间的提升由项目经理批准，从组工作空间向基线空间的提升由CCB评审批准，均由CM工程师执行。
提升后删除原空间的配置项。
产品空间用Tag的方式标识不同版本的产品。
例如，软件需求规格说明书在编写或修改时，放到作者的个人空间进行管理，经过评审后，提升到相应的“211 需求规格说明书”目录中，形成基线后，再提升到“110 需求规格说明书”。
CMMI 3标准文档模板第13章系统测试 (1)13.1 介绍 (1)13.2 系统测试规程 (2)13.2.1目的 (2)13.2.2角色与职责 (2)13.2.3启动准则 (2)13.2.4输入 (2)13.2.5主要步骤 (3)[Step1] 制定系统测试计划 (3)[Step2] 设计系统测试用例 (3)[Step3] 执行系统测试 (3)[Step4] 缺陷管理与改错 (3)13.2.6输出 (3)13.2.7结束准则 (4)13.2.8度量 (4)13.3 实施建议 (4)第13章系统测试系统测试（System Test, ST）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
系统测试过程域是SPP模型的重要组成部分。
本规范阐述了系统测试的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
13.1 介绍系统测试流程如图14-1所示。
由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束。
这样可以提高系统测试的效率。
系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。
图13-1 系统测试流程图项目经理设法组建富有成效的系统测试小组。
系统测试小组的成员主要来源于：✧机构独立的测试小组（如果存在的话）。
✧邀请其它项目的开发人员参与系统测试。
✧本项目的部分开发人员。
✧机构的质量保证人员。
系统测试小组应当根据项目的特征确定测试内容。
一般地，系统测试的主要内容包括：✧功能测试。
即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。
某某区电子政务系统测试分析报告版本 <0.1>修订历史记录目录1.简介 (4)1.1目的 (4)1.2范围 (4)1.3定义、首字母缩写词和缩略语 (4)1.4参考资料 (4)1.5概述 (4)2.测试结果摘要 (5)2.1测试总结 (5)2.2测试简介 (5)2.3测试机构和人员 (5)2.4测试环境 (5)3.基于需求的测试覆盖 (6)3.1测试结果汇总表 (6)3.2源程序代码行及千行代码错误率统计 (6)3.3系统缺陷提出情况 (7)3.4缺陷修改情况 (7)4.评价 (7)测试分析报告1.简介某某区电子政务系统测试分析报告是以真实有效的测试数据为依据，并结合需求规格说明书和概要设计说明书，得出的相关项目现阶段开发成果分析报告。
1.1目的本文档是依照某某区电子政务系统的测试计划及测试用例进行测试后，汇总得出的报告，并对测试结果进行分析。
因此，它既可以成为纠正软件缺陷的依据，也可以为软件验收和交付打下基础。
1.2范围本文档适用于某某区电子政务系统分析阶段及试运行前阶段。
本文档只是针对试运行前阶段的本项目的测试分析报告，不包括项目实施中，以及项目试运行后系统作的一些修改的回归测试。
本文档的预期读者包括：✧高级管理者――根据此文档了解相关项目的进展及其它情况。
✧质量保证人员――依据此文档提供的数据，对该项目的质量作出评估。
✧项目经理及开发人员－－对项目的当前状况进行分析并提出相应改进措施。
✧软件测试人员――对相关项目的前阶段测试工作做出总结。
1.3定义、首字母缩写词和缩略语PW-HSEGOV ——某某区电子政务系统1.4参考资料1.5概述本文档包括“测试结果摘要”、“基于需求的测试覆盖”及“评价”3个方面的内容，其中：➢测试结果摘要：主要对本次测试的最后结果进行总结，包括测试的通过情况、测试机构和人员的介绍以及测试环境的相关情况。
➢基于需求的测试覆盖：主要是参考需求说明书，对测试结果进行汇总，并列举出了缺陷的分布情况等信息。
项目层级配置管理员1.请叙述您如何识别配置项? (CM SP1.1)回答：作为配置管理员，需要配合项目经理在项目策划阶段，依据项目已定义过程及裁剪的结果，识别项目需要管理的配置项。
定义在项目的配置管理计划中。
为了方便管理这些配置项，我们将这些配置项归属到项目不同的基线进行管理，比如我们定义了6条基线，分别是：策划基线、需求基线、设计基线、代码基线、测试基线、发布基线，基线中包含的配置项如下所示：2.请叙述如何建立配置管理系统?如何利用CM tool进行版本控管? (CM SP1.2)回答：选择配置管理工具在目前阶段，本公司规定所有项目组一致使用SVN作为配置管理工具。
使用配置管理工具创建配置管理系统，并在配置管理计划中定义配置项存放的路径及访问权限3.项目策划了哪些基线？基线建立的过程是什么? (CM SP1.3)回答：1.基线建立的目的是为了保证基线中文档的完整性和正确性2.项目规划的基线包括有：策划基线、需求基线、设计基线、代码基线、测试基线、发布基线3.这些基线及基线中所属配置项，都定义在《配置管理计划》中，比如需求基线中应该包括：….4.按照配置管理计划中定义的基线发布时机和内容，进行发布，发布时a.项目组编写“基线建立申请”，提交CCB审批。
B审批通过后，配置管理员完成物理审计和功能审计，并填写“发布报告”，进行基线发布4.您如何管制配置项的变更? 配置项受控后，如何实施变更？(CM SP2.1/SP2.2)回答：1.公司的变更管理过程的定义是这样的a.变更申请：由于基线变更或其他引起的变更，变更申请人向项目经理提交“变更请求单”（包括：变更的理由、变更的影响、变更带来的工作量、进度、风险等方面的变化分析）。
项目经理对变更进行评估。
b.审批变更申请：CCB审批该申请，分析此变更对项目造成的影响。
如果同意变更，则批准，否则终止此次变更。
c.实施变更：1.项目经理将变更请求的审批结果告知配置管理员。
