电网公司SOA技术电力设施过程管理实施方案.docx

《电网公司SOA技术电力设施过程管理实施方案.docx》由会员分享，可在线阅读，更多相关《电网公司SOA技术电力设施过程管理实施方案.docx（72页珍藏版）》请在三一办公上搜索。

1、 广东电网公司基于SOA技术的电力设施全过程管理项目技术建议书广东电网公司基于SOA技术的电力设施全过程管理项目实施方案和进度计划深圳市康拓普信息技术有限公司Shenzhen Comtop Information Technology Co.,Ltd.2009年11月深圳市康拓普信息技术有限公司 II 广东电网公司基于SOA技术的电力设施全过程管理实施方案和进度计划目录第1章 实施方案11.1 实施方法论11.1.1 第一阶段：项目准备21.1.2 第二阶段：业务蓝图设计31.1.3 第三阶段：业务蓝图实现31.1.4 第四阶段：投入运行准备41.1.5 第五阶段：系统投入运行及支持41.2

2、项目实施方案51.2.1 项目准备阶段51.2.2 业务蓝图设计阶段61.2.3 业务蓝图实现阶段81.2.4 投入运行准备阶段91.2.5 系统投入运行及支持阶段111.3 测试实施方案121.3.1 测试策划121.3.2 测试设计131.3.3 测试执行131.3.4 缺陷管理161.3.5 测试类型23第2章 项目管理方案282.1 项目管理282.1.1 需求管理282.1.2 配置管理322.2 质量保障332.2.1 文档评审332.2.2 系统测试342.2.3 质量保证342.2.4 配置管理342.3 项目实施风险352.3.1 潜在的风险和应对方法352.3.2 潜在的难

3、点和应对方法372.4 项目组织及人员组成382.4.1 项目组织结构382.4.2 各小组职责和人员构成382.4.3 项目组成员介绍402.5 项目进度602.6 项目交付项612.6.1 第一阶段交付物612.6.2 项目技术环境配置清单第二阶段交付物612.6.3 第三阶段交付物622.6.4 第四阶段交付物622.6.5 第五阶段交付物632.7 培训方案。632.7.1 培训内容632.7.2 培训方式642.7.3 培训课程65 广东电网公司基于SOA技术的电力设施全过程管理实施方案和进度计划第1章 实施方案1.1 实施方法论Accelerated Implementation

4、Methodology (AIM)是康拓普公司为使项目实施更简单、更有效的一套完整的实施解决方案。AIM优化了在实施过程中对时间、质量和资源的有效使用等方面的控制，是一个包括了使得项目实施得以成功所有基本要素的完整的实施方案。经过多年的项目实践，这套方法已经在康拓普公司实施的多个项目包括广东、广西、北京、上海、福建、贵州、四川、安徽、成都等多个省级电网公司的重要项目中得到验证，取得非常好的效果。AIM 提供了面向过程的，清晰和简明的项目计划，为实施电力设施全过程管理系统项目的整个过程提供指导。路线图共有五步：l 项目准备l 业务蓝图设计l 业务蓝图实现l 投入运行准备l 系统投入运行及支持图

5、实施方法论路线图1.1.1 第一阶段：项目准备1) 目的： 确定项目主要目的和重点 确定项目的实施范围和策略 确定项目组织结构及成员 制定实施计划和标准 准备并安排各方面资源2) 主要任务： 成立项目相关小组 项目的初步实施计划 制定项目实施的规范及标准 启动项目 技术环境的分析与规划 质量检查1.1.2 第二阶段：业务蓝图设计1) 目的： 项目目标明细化 确定项目的详细实施计划 业务需求的差异分析 企业组织结构及业务流程的确定2) 主要任务： 项目管理 项目小组基础培训 建立系统技术环境 企业组织结构确定 企业业务流程确定 功能需求差异分析 质量检查1.1.3 第三阶段：业务蓝图实现1) 目

6、的： 逐步实现业务蓝图 完整的系统测试 用户对系统的确认2) 主要任务： 项目管理 基本系统配置及确认 开发应用接口程序 报表定义 权限定义及管理 系统集成测试 用户手册及用户培训资料 质量检查1.1.4 第四阶段：投入运行准备1) 目的： 完成系统上线的准备，以保证系统正确运转 解决剩余问题2) 主要任务： 项目管理 用户培训 正式运行技术环境的安装及测试 制定明细运行计划 制定系统运行支持计划 质量检查1.1.5 第五阶段：系统投入运行及支持1) 目的： 正确移交系统 保证系统正常运转2) 主要任务: 确认正式业务流程的正确性 优化系统的使用 后续培训 制定后续长期计划 系统升级 系统日常

7、维护 项目回顾1.2 项目实施方案根据康拓普快速实施方法论，结合广东电网公司电力设施全过程管理系统建设项目的实际，我们提出了本项目的实施方案。在本方案中，我们明确了每个项目阶段的目的、工作任务、主要工作成果。1.2.1 项目准备阶段1.2.1.1 目的正式建立康拓普公司及建设单位的项目小组，明确项目目标、范围并分配双方的工作职责和任务，制定项目实施计划。1.2.1.2 任务 成立项目相关小组分别成立康拓普公司和建设单位的相关项目小组，包括：项目领导小组、信息技术小组、专业小组、数据清理小组等，确定各方项目小组成员的工作角色及责任，确定互相沟通的方式、项目组的纪律和工作时间表。 正式启动项目建设

8、单位组织项目相关人员召开启动会议，会议明确项目目标、项目范围，项目组织结构及里程碑等内容。 制定项目实施计划康拓普公司及建设单位结合项目建设目标，讨论制定项目初步实施计划，明确项目实施进度并分配双方的工作任务。 规划项目技术环境康拓普公司基于项目平台配置要求，结合建设单位信息化环境，提交项目技术环境配置列表，明确项目所需软硬件及第三方平台配置。1.2.1.3 主要工作成果 项目组织结构文件 项目实施方案文件 项目实施计划文件 项目技术环境配置清单1.2.2 业务蓝图设计阶段1.2.2.1 目的根据项目范围并结合建设单位相关管理业务需求，组织项目相关专业小组开展功能需求分析，提交经双方讨论确定的

9、核心设计成果；基于建设单位现有业务流程，讨论、修改并确认未来业务流程设计；完成项目接口调研与分析。结合业务蓝图设计阶段成果细化项目实施计划，并以此为指导启动所有后续实施工作。1.2.2.2 任务 确认建设单位企业组织结构建设单位提交企业组织机构及其岗位职能说明，经双方讨论确认后形成项目职能边界，指导后续业务流程设计、功能需求差异分析。 组织数据审查康拓普公司组织资管理部门评估原库存数据和原过程单据数据。 组织功能需求分析康拓普公司组织建设单位相关管理部门，结合项目系统原形，完成系统功能与业务需求之间的差异分析。 系统架构设计康拓普公司项目组架构设计师进行系统总体架构设计、项目管理部分架构设计、

10、物资管理部分架构设计、设备管理部分架构设计和财务管理部分架构设计。 完成业务流程定义康拓普公司组织建设单位相关管理部门项目组，结合建设单位相关管理实际，完成项目业务流程的设计与定义。 完成接口调研与分析康拓普公司组织开展接口需求调研工作，完成项目建设单位系统接口需求分析与设计。 确认项目详细的实施计划康拓普公司及建设单位结合业务蓝图设计阶段成果，进一步细化项目实施计划，并以此为指导启动所有后续实施工作。1.2.2.3 主要工作成果 电力设施全过程管理系统业务需求说明书 电力设施全过程管理系统需求差异分析表 电力设施全过程管理系统业务流程设计文件 电力设施全过程管理系统接口调研分析报告 电力设施

11、全过程管理系统接口技术方案1.2.3 业务蓝图实现阶段1.2.3.1 目的本阶段的目的是开发、测试建设单位的软件系统及接口。在此阶段，康拓普公司将对建设单位设计/重设计阶段产生的未来业务流程、功能需求差异及接口技术方案进行更详细地设计和分析，完成电力设施全过程管理系统软件开发，并最终对结果进行集成测试。1.2.3.2 任务 系统开发与配置康拓普公司组织开发人员，结合建设单位功能需求差异与业务流程设计，完成电力设施全过程管理系统开发与配置。 接口开发与调试n 根据广东电网公司的安排部署，康拓普公司在各建设单位进行需求及应用系统现状调研。给出各建设单位与电力设施全过程管理系统有关的各应用系统的实际

12、运行情况；n 组织需求分析人员进行接口和信息模型定义，给出满足各方约束、符合各建设单位要求的方案；n 康拓普协调、组织评审接口方案的合理性和适用性；n 接口方案通过评审以后，康拓普公司安排技术专家协助各建设单位实现需求调研期间确定的所有接口服务，并完成单机调试与测试工作；n 进行建设单位调试工作。 制定集成测试计划，进行集成测试；康拓普公司制定集成测试计划，完成电力设施全过程管理系统集成测试，提交项目集成测试报告。 确认系统权限配置；康拓普公司收集最终用户系统权限配置，完成电力设施全过程管理系统权限初始化。 制定最终用户培训计划；康拓普公司及建设单位结合项目实施计划，讨论制定最终用户培训计划。

13、 进行系统功能验收建设单位组织相关人员召开项目验收会议，完成电力设施全过程管理系统功能测试与验收。 制定系统切换计划；康拓普公司结合建设单位信息化环境制定系统切换计划，明确系统切换步骤与系统切换应急预案。1.2.3.3 主要工作成果 电力设施全过程管理系统配置数据； 电力设施全过程管理系统权限分配表； 电力设施全过程管理系统集成测试计划及测试记录报告； 通过集成测试的电力设施全过程管理系统； 通过集成测试的接口服务； 功能验收报告； 电力设施全过程管理系统培训计划； 系统切换计划。1.2.4 投入运行准备阶段1.2.4.1 目的在此阶段将通过用户验收测试的系统切换到正式系统，完成系统培训及投入

14、运行前的准备工作。1.2.4.2 任务 进行数据的最后收集与确认建设单位完成系统基础数据的最后收集与确认。完成系统配置数据、用户权限数据、业务流程数据的最终确认。 制定最终用户手册康拓普公司完成用户手册的编写工作。 完成最终用户的培训康拓普公司组织实施人员，开展电力设施全过程管理系统培训，分批完成最终用户培训。 完成正式系统切换；康拓普公司组织技术人员进行系统环境及数据准备，完成系统测试环境到运行环境的切换。 制定明细运行计划及系统运行支持计划；康拓普公司协助建设单位完成明细运行计划及系统运行支持计划的制定。 制定运行维护管理制度；康拓普公司协助建设单位完成运行维护管理制度的编制。1.2.4.

15、3 主要工作成果 电力设施全过程管理系统最终用户使用手册； 电力设施全过程管理系统最终用户培训教材； 电力设施全过程管理系统明细运行计划； 电力设施全过程管理系统运行支持计划； 电力设施全过程管理系统运行维护管理制度； 交付使用的电力设施全过程管理系统。1.2.5 系统投入运行及支持阶段1.2.5.1 目的系统投入运行及支持阶段使系统成为一个实际应用中的系统，并确保其具有稳定的操作性能。该阶段包括了问题解答和用户帮助。1.2.5.2 任务 确认正式业务流程的正确性康拓普公司收集实际应用环境业务流程改进，确认正式业务流程的正确性。 优化系统的使用康拓普公司组织测试人员进行性能测试，完成实际应用环

16、境的性能配置与调优。 系统上线支持康拓普公司负责本阶段系统上线支持，提供现场技术支持、故障紧急恢复、故障的软件补丁升级以及问题解答服务。 完成初步验收建设单位组织相关人员召开初步验收会议，开展电力设施全过程管理系统功能现场初步验收。1.2.5.3 主要工作成果 性能测试记录报告； 问题处理备忘录； 服务支持备忘录； 初步验收报告。1.3 测试实施方案1.3.1 测试策划1.3.1.1 流程图 图 测试策划流程1.3.1.2 活动描述在需求基线建立后，测试工程师启动测试需求分析活动： 识别测试范围 识别出可重用的测试用例 标识出自动化测试部分 初步确定测试类型（例如：功能测试、性能测试、界面测试

17、、兼容性测试等） 确定所需的测试环境和工具测试工程师根据开发计划、需求规格说明书及测试需求分析结果编写系统测试计划和系统测试进度计划。系统测试计划是可裁剪的，系统测试进度计划是必须的；系统测试进度计划必须进行评审，以确保时间上能与开发进度相一致，并且保证整个软件测试活动是有序的。1.3.2 测试设计1.3.2.1 活动描述测试工程师编写系统测试用例。以需求规格说明书、需求特征项作为主要的依据，设计文档、实际可运行的程序原型可作为编写的辅助材料。在编写过程中，应多与分析、设计人员沟通，不明确的地方以项目经理的答案作为衡量标准。系统测试用例的评审先在测试组内部进行评审，评审通过后在项目组内进行评审

18、。项目组的评审由项目组各类成员的代表共同参与，特别是熟悉需求和设计的代表必须参加，评审的具体形式可根据项目开发计划中的要求进行。测试组内部评审时，需要使用系统测试用例检查表。评审前测试人员应讲解测试用例的编写思路、主要的关键点，以达到评审的有效性。测试用例必须覆盖需求，以及与系统功能的一致性。测试用例的编写和评审根据项目组所选生命周期进行，逐步完善；在整个设计过程中，可以阶段性的部分评审，但在正式测试前应至少完成一次整体性的评审。1.3.3 测试执行1.3.3.1 流程图图 测试执行流程1.3.3.2 功能测试准备提交系统测试时，项目经理安排测试申请人在发布系统前检查代码是否入库，并通知相关人

19、员检查实现与设计的一致性、通知测试组预计能进行系统演示的时间。提交功能测试的前提条件：在测试范围内，QC库中无“new、Open、Reopen”状态的缺陷（只限于“系统演示”、“系统测试”发现的缺陷）。测试系统部署后，项目经理提交功能测试任务单，并进行系统演示。功能测试任务单主要内容包括： 被测系统版本号及代码行。 预计测试开始与结束时间（对系统进行全面测试时，项目组至少预留3天的测试时间；如果进行部分模块测试或缺陷验证，至少预留2天的测试时间）。 填写该版本修改的需求特征项，指明本次测试的要点。 注明需验证缺陷的范围。系统首次提交功能测试时，项目经理或指定软件工程师需先根据产品介绍文档讲解系

20、统需求及业务逻辑，然后进行系统的全面演示。系统演示开始时确定记录人，由记录人记录发现的缺陷，并在会后录入QC库进行跟踪。系统演示后，测试人员认为系统具备基本的可测试性，则抽取10的特征项进行验证，检查实现与需求规格说明书的一致性。特征项由测试组和项目组共同协商确定，并将抽取的特征项记录在功能测试任务单上，发现的缺陷录入QC。提交功能测试时，一般都需要全面演示，如果有特殊原因不进行演示，必须经过质量管理部经理（负责测试）的同意。系统演示必须在测试环境中执行，项目组需要将程序发布到测试服务器上，在测试过程中项目组不得更新被测系统和数据库。转测试通过后，项目经理通知配置管理员对测试系统进行预编译。预

21、编译完成后，发布人通知测试人员，并将预编译结果提交项目经理（不必录到QC库）。一轮测试结束后，测试人员在一个工作日内将测试结果及主要情况、缺陷统计反馈填写在功能测试任务单上，提交给项目经理审核，项目经理电子签名确认，标志着一轮测试任务的结束。测试任务单需存放在各项目组的配置库中。项目上线后一个月集中以会议形式给测试组演示需求/功能上的变更，在演示后，测试人员根据演示情况更新测试用例。1.3.3.3 性能测试功能测试通过后，项目经理根据系统的实际情况，提出性能测试申请，向测试组提交性能测试任务单。测试工程师执行性能测试前需要编写性能测试计划，跟项目经理或主要开发人员确定性能测试的范围和各项性能预

22、期指标，编写性能测试脚本，组织和执行性能测试，并作好观察和记录。1.3.3.4 其它类型测试项目组可根据系统的实际需要，向测试组提出功能及性能测试以外的测试申请，比如：兼容性测试。此类测试不需要演示，只要具备测试条件（系统功能比较稳定）即可进行。项目组需要提交相应的测试任务单。1.3.3.5 测试总结在项目开里程碑会议时，提交阶段的系统测试总结报告；在项目结项时，对整个测试活动进行总结，提交项目的系统测试总结报告。测试组将系统测试总结报告提交给项目组前，需进行内部审核。1.3.4 缺陷管理1.3.4.1 角色与职责角色职责项目经理负责提交系统测试，分配处理测试发现的缺陷。测试工程师执行测试，录

23、入缺陷，验证、关闭修改后的测试缺陷。修改人修改测试、评审的缺陷。记录人记录评审、走查发现的缺陷，录入QC。跟踪人跟踪、验证、关闭修改的评审缺陷。1.3.4.2 缺陷分类缺陷引入阶段：指在项目哪个阶段（过程）引入的缺陷。选项：策划阶段、需求阶段、设计阶段、编码阶段、测试阶段、发布阶段、投入运行阶段。填写角色：缺陷修改人。说明：不是项目当前所处阶段。该阶段可理解为过程，不是指项目开发周期，而是在本周期所处的活动阶段。缺陷严重等级：指该缺陷造成影响的严重等级。填写角色：缺陷记录人严重等级名称缺陷等级描述高High严重地影响系统要求或基本功能的实现，影响系统的稳定性、造成数据存储错误或将错误数据带入下

24、一环节、一些重要特性或性能不能达到指定的要求等。中等Medium功能可以使用、在出错后做出一定处理，操作能够继续进行或功能实现有误，但问题的出现应不影响本功能或其他功能的实质性使用。低Low用户界面显示、对齐、文字错误等。建议Suggestion测试人员对系统的一些建议，不影响系统的使用功能，项目经理可根据实际情况决定是否修改。不算做缺陷，不用于缺陷的统计、分析、度量。缺陷类型：这其中包含了两个纬度的概念，为了方便填写合成一个缺陷分类。 选项：测试、评审（技术缺陷）、评审（非技术缺陷）填写角色：缺陷记录人。技术缺陷：指项目工程文档发现的、跟软件工程相关的缺陷。如：需求文档中用例编写错误、设计文

25、档中设计错误、需求遗漏、代码变量定义有误等。非技术缺陷：指文档格式类、文字类、管理类问题。如：软件开发计划发现的问题、页眉页脚问题、错别字问题、代码注释问题等。说明：测试缺陷都属于技术缺陷。评审包括了正规评审和走查的缺陷。缺陷根源：导致缺陷发生的深层次的根源。选项：需求不明确、计划安排不合理、人员技能不足、重要评审员没有参与、评审投入时间不过、评审没有进行。填写角色：缺陷修改人。说明：比如该缺陷是由设计错误造成的，追溯其根源就可能是：人员技能不足或评审没有进行等根本性原因。缺陷发现活动：选项：文档评审、代码走查、功能测试、性能测试、界面测试、兼容测试、安全性测试。填写角色：缺陷记录人1.3.4

26、.3 缺陷处理过程1.3.4.3.1 缺陷状态状态名称英文名称描述新发现New缺陷录入QC的初始状态打开Open缺陷分配后的状态已修改Fixed缺陷修改后的状态被拒绝Rejected缺陷未被接受状态重新打开Reopen缺陷未通过验证的状态已关闭Closed通过验证的缺陷状态暂缓Respite接受修改，但暂缓修改的缺陷状态冻结Frozen无法修改的缺陷状态1.3.4.3.2 评审缺陷处理流程评审（包括正规评审和走查）发现的缺陷都必须录入QC库进行管理和跟踪，并要求在一周内关闭。1.3.4.3.2.1 评审缺陷处理流程图 评审缺陷处理流程1.3.4.3.3 测试缺陷处理流程测试过程中最重要的工作产

27、品就是在测试过程中发现的缺陷问题，如何对每一个缺陷问题进行全生命周期的管理，不遗漏任何一条有价值的缺陷，是保证软件高质量的关键基础之一。以下图为例，康拓普公司对于每一个测试发现的缺陷从一开始的记录，到分配、修复、验证、关闭都有清晰的全过程的记录和管理。1.3.4.3.3.1 测试缺陷处理流程图 测试缺陷处理流程1.3.4.4 缺陷分析1.3.4.4.1 缺陷统计缺陷统计是为了帮助未来项目设定量化的质量目标，理解和控制未来项目的实际结果，为缺陷预防奠定基础。 缺陷统计只针对技术缺陷（即缺陷类型为测试和评审（技术缺陷），非技术缺陷不纳入统计的范围。项目组进行阶段总结时，测试工程师针对消缺率、及时消

28、缺率、一次性通过率、Reopen率、缺陷周期、缺陷引入阶段、缺陷根源等指标对缺陷情况进行统计，生成缺陷统计报告，提交项目经理。项目经理根据统计结果进行分析。 消缺率：展现对缺陷或建议的修复或采纳情况。 及时消缺率：展现缺陷的消缺及时性。 一次性通过率：展现里程碑提交测试的系统一次性转测试通过的情况。 Reopen率：展现缺陷的修复质量。 缺陷周期：展现QC库中未关闭缺陷的生命周期情况。 缺陷引入阶段：按照缺陷引入阶段进行统计，便于项目组进行缺陷分析。 缺陷根源：按照缺陷产生的根源分类进行统计，便于项目组进行缺陷分析。1.3.4.5 缺陷预防缺陷预防的着眼点在于缺陷的共性原因，通过找寻、分析和处

29、理缺陷的共性原因，实现缺陷预防。缺陷预防包括分析过去所碰到的缺陷和采取相应的措施以避免这些缺陷在以后再出现。这些缺陷可能发生在当前项目的早期阶段，也可能发生在其它项目中，所以缺陷预防活动是不同项目间互相汲取教训的有效手段。1.3.5 测试类型为了严格地保障本系统系统的系统质量，提高用户对系统的使用满意度，本次系统测试将对本系统进行以下五个类型的测试：功能测试、性能测试、界面测试、兼容性测试、安全性测试。序号测试类型是否执行1功能测试2性能测试3界面测试4兼容性测试5安全性测试1.3.5.1 测试策略主要依据国家/国际相关的测试标准和规范(GB/T 17544-1998信息技术 软件包 质量要求

30、和测试)针对本方案中要进行的五种测试类型：功能测试、性能测试、界面测试、兼容性测试与安全性测试，对于每一种测试类型的测试方法和策略进行描述。1.3.5.1.1 功能测试功能测试的整体策略是分两个阶段，第一阶段是对每个子系统中的每个功能进行单独地测试；第二阶段是根据本系统的关键，常用的业务流程，把多个功能串起来进行的流程测试。功能测试要覆盖各个子系统中各个模块中的每个功能。在功能测试时采取正向和反向两种方式，既要输入正确的数据，测试功能是否满足，也要对每个功能中的每个数据输入域故意输入错误的数据，测试系统的健壮性。比如：要求输入字符的测试是否可以输入数值，要求输入数值的测试是否可以输入字符，是否

31、有输入长度的限制、非空限制、大小写的限制、最大最小值（边界值）的限制等等。在每个功能测试通过的基础上，可以开始业务流程的测试，根据每个业务流程中所涉及到的多个功能，将各个相关的功能按一定的顺序连接起来进行业务流程的测试。在系统功能较稳定的情况下，会通过自动化测试工具（QuickTest Profissional）进行回归测试，以保证测试的全面性与连续性。1.3.5.1.2 性能测试系统的性能一般指系统的响应时间和并发用户数。在系统响应时间明显比较长的地方将在测试程序中插入记时器来进行记时，可以得到系统响应的实际时间，将实际使用时间与要求时间进行对比就可以得出是否符合要求的结论；对于并发用户数的

32、测试将在条件允许的情况下用自动化性能测试工具，来编写自动化测试脚本，产生模拟用户来执行性能测试，因为人工能够实际模拟的并发用户数比较有限。项目的性能测试将根据系统的具体的性能指标要求，来设计和执行。目前我们使用LoadRunner进行系统的性能测试，出具专业的性能测试报告，通过报告指标找出性能瓶颈，经过性能调优后，系统响应时间在10秒以内，支持并发50个用户的负载性能，可稳定运行200个用户同时在线。1.3.5.1.3 界面测试系统界面测试对于用户来说，也是非常重要的，界面是一个应用软件系统与用户进行的直接交互。系统操作的方便性，易用性，美观性都是界面测试的主要内容，所以在进行功能测试的同时还

33、要关注系统用户界面的问题，主要从以下两个方面进行考虑：实用性：用户界面操作的方便性、友好性，是否符合常规的一些习惯，是否提供必要的快捷键，对于同类型的重复操作是否有快捷方式等等。美观性：各界面的风格是否一致，控件是否排列整齐，大小是否合适、位置是否合适等等外观性的评价。1.3.5.1.4 兼容性测试考虑到本系统的使用范围将非常广，比如系统将为多个相关的管理部门提供使用，那么系统将面临着多种多样的客户端环境，所以对系统进行兼容性测试也是非常有必要的。兼容性测试的策略主要是依据用户群中主要的各种常见的软件环境，从操作系统版本、OFFICE版本、IE版本等方面进行组合考虑。在不同的环境下进行系统的客

34、户端测试，找出系统在兼容性方面的一些缺陷，及时地修复，将给系统未来的推广使用打下良好的基础。1.3.5.1.5 安全性测试主要从系统登录、用户权限、超时设置等方面验证系统的安全性。 输入有效和无效的用户名和密码，验证系统登录功能是否正常；是否可以不登陆而直接浏览某个页面等。 是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。 用户的操作权限：以不同角色登录系统，检验各个角色的操作权限是否正确、合理。如果系统中有权限分配的功能，对用户进行授权，再以被授权的用户登录系统，检验操作权限。1.3.5.2 测试资源1.3.5.2.1 测试工

35、具在本项目的系统测试过程中将使用到以下测试工具：Quality Center(简称：QC)：测试管理工具，主要用途为管理测试需求，设计测试用例，记录和跟踪测试中所发现的缺陷等。LoadRunner(简称：LR)：自动化性能测试工具，主要用途为编写自动化性能测试脚本，设计性能测试场景，模拟多用户的并发测试。QuickTest Profissional(简称：QTP)：自动化功能测试工具，主要用途为编写功能测试脚本，执行回归测试。1.3.5.2.2 测试环境要求为了保证测试的有效性，测试环境需要独立，必须与开发环境分开。测试服务端：硬件、软件环境的配置要求是与系统运行的正式环境一致或类似。测试用客

36、户端： 硬件：PC 5-10台(CPU2.4G ，内存512M) 软件：windows 2000/xp/2003，Office 2000/xp/2003， IE版本6.0 、SP1、SP2 测试数据：系统中需要有一定数据量的各类业务数据 测试网络环境要求：康拓普内部局域网，局域网采用千兆以太网1.3.5.2.3 人员配备系统测试负责人：1人职责：负责与开发组之间的沟通，协调测试所需的资源和环境，制定测试计划，监督测试过程。测试小组：610人职责：根据测试方案和测试进度计划的安排，完成方案中涉及的各类测试工作，主要包括系统的功能测试、性能测试、界面测试、兼容性测试和安全性测试。1.3.5.3 测

37、试实施1.3.5.3.1 测试准备阶段项目开发计划评审通过后，测试负责人进行测试需求分析，根据开发计划、开发进度计划和测试需求分析结果，编写测试计划及测试进度计划。1.3.5.3.2 测试设计阶段系统需求规格说明书评审通过后，测试工程人熟悉需求、分析需求，参照需求规格说书明、需求特征列表，采用等价类划分、边界值分析、错误推断等多种方法进行系统测试用例设计。1.3.5.3.3 测试执行阶段系统开发出某一版本并由项目组提交测试后，测试工程师根据测试用例，执行系统功能测试、界面测试、兼容性测试和安全性测试，测试发现的缺陷通过QC向项目组反馈；缺陷修改完毕后再进行回归测试。待系统功能比较稳定后，根据系

38、统性能指标要求编写性能测试计划，调试性能测试脚本，准备测试环境，执行性能测试，性能测试结束后，出具性能测试报告，通过报告指标找出性能瓶颈，开发人员进行性能调优。系统测试结束后，测试组编写系统出厂测试报告，执行出厂测试。1.3.5.3.4 测试总结阶段系统出厂测试结束后，编写系统现场测试报告，提交给用户，用于验收测试时使用。测试组对整个系统测试工作进行总结，交流经验教训，向EPG提交最佳实践、正反样例等，编写该项目的测试总结报告。第2章 项目管理方案2.1 项目管理SW-CMM(Capability Maturity Model For Software 软件生产能力成熟度模型，以下简称“CMM

39、”)，是1987年由美国卡内基梅隆大学软件工程研究所（CMU SEI）研究出的一种用于评价IT承包商能力并帮助改善软件质量的方法，其目的是帮助IT企业对IT系统项目过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。CMM它是目前国际上最流行、最实用的一种IT企业适用的生产过程标准，已经得到了众多国家以及国际IT产业界的认可。康拓普公司于2008年通过了CMMI3级的评审。建立了一套项目的开发、测试与维护完整的质量体系。编制了一套项目过程管理指南作为项目过程管理的指导，内容涵盖了CMMI3级需求管理、软件策划、软件跟踪与监督、配置管理、质量保证等KPA的要求。包

40、括了：技术评审规程、测试规程等规程；迭代开发、设计界面雏形与用例说明、设计领域模型、技术评审、变更控制、持续集成、缺陷管理、系统发布等关键实践。本项目将严格按照项目过程管理指南的要求来管理开发过程。2.1.1 需求管理2.1.1.1 需求调研在售前阶段已进行前期需求调研，确定了项目的工作范围。本阶段需求调研的目的是要详细了解用户实际的业务流程，并整理需求细节，形成SOW正式稿、软件估算、软件开发计划、软件进度计划，并着手编写需求规格说明书。调研准备项目经理确定调研的方法，选择有代表性的调研对象（如：最终用户、维护人员），拟定调研计划。开展需求调研之前，项目经理需提前准备好调研提纲，发送给客户，

41、内容包括：交流的目的、调研内容、形式、客户参与人员等，并和客户协商调研的具体时间、地点。常用的调研方法有：访谈（钻石型、金字塔型、圆锥型）、调查问卷、界面原型、系统演示、联合开发、头脑风暴。调研时一定要挖掘用户深层次的需求（Need，Need与Requirement不同），即提出需求的背后动机、真正期望。在调研时可以有意识地问用户为什么提出该需求。调研结果应服务于下列目标：有效提高对业务的理解水平、规避后期需求变更的风险、聚焦项目范围、有效开展版本规划活动。 调研结果需求调研会议结束后，调研人员需在1个工作日内完成需求调研会议纪要，如有必要还需发送给客户确认，并入配置库。项目组根据用户的需求编

42、写界面原型、创建项目特征库、 编写需求规格说明书的业务描述部分并绘制业务流程图，通过界面原型、业务流程图来进一步确认用户的需求。2.1.1.2 缺陷预防在开始需求分析之前，由程序经理组织召开需求缺陷预防会议，QA指导，包括下列活动： 选择并学习与需求相关的典型缺陷案例。 选择正反面典型需求文档样例进行点评。 学习以往项目组最佳实践，吸取以往项目组的教训。2.1.1.3 需求分析1根据调研会议纪要、业务流程图、界面原型、客户业务相关规章制度、需求规划列表，由程序经理、系统分析师进行需求分析： 识别actor，识别系统用例，识别业务规则（如：工作类别=检修/试验/巡视；计算公式），编写系统用例描述

43、。 建立领域模型，编写中英文对照的术语表。 分析性能、安全等非功能性需求。 分析系统接口需求。 完善特征项。 演进界面原型，与用户确认。2重用小组（技术研究部）人员参与项目组需求分析，识别项目可贡献的重用模块或组件，以及项目组可以使用的重用组件，并参与该部分重用模块或组件的需求分析和设计。3依据分析结果编写需求规格说明书。4建立需求跟踪矩阵。2.1.1.4 评审与审核需求需求文档（需求规格说明书、领域模型、特征项、界面原型）要求进行需求评审和需求审核：需求评审：是在项目组内部按模块进行评审。需求审核：是对项目组内达成一致的需求文档进行的评审。需求确认：必要时将最新的成果与客户进行确认。2.1.

44、1.5 建立需求基线需求文档评审（不是指需求审核）通过后，表示需求定稿，项目经理通知SCM建立需求基线。需求基线包括：工作任务书、软件开发计划、界面原型、需求规格说明书、特征项、需求规划列表、项目估算、生命周期与流程裁剪必须建立需求基线后才能进行下一阶段工作。对于迭代型生命周期，在每个开发周期的需求分析完成后，建立需求基线。2.1.1.6 测试需求分析在需求基线建立后，测试工程师启动测试需求分析活动： 识别测试范围 识别出可重用的测试用例 标识出自动化测试部分 初步确定测试类型（例如：功能测试、性能测试、界面测试、兼容性测试等） 确定所需的测试环境和工具2.1.1.7 编制测试计划测试工程师根据软件开发计划、软件开发主进度计划、需求规格说明书及测试需求分析结果编写系统测试计划和系统测试进度计划。2.1.1.8 需求变更需求基线建立后，需求发生变更时，必须按照变更管理规程进行需求变更。2.1.1.9 变更控制已受控的配置项发生变更时进入变更管理流程。配置项受控原则：配置项已纳入基线。如：需求规格说明书受控原则为需求基线已建立，领域模型受控原则为设计基线已建立，代码受控原则为发布基线已建立。变更来源：客户问题或者项目组提出的功能改进。变更管理流程见下图：变更管理流程图