软件项目实施方案书

项目实施方案书

一、 项目实施总体目标 .................................... 6 二、 项目建设阶段实施组织计划 ............................ 6

1.1. 项目组织架构 .................................... 6 1.2. 实施方案的职责划分 .............................. 9

项目实施过程中 ................................... 9 上线后的运行维护阶段 ............................ 10 1.3. 项目概要实施计划 ................................ 12 1.4. 项目工作阶段和内容 .............................. 18

................................................ 18 分析阶段 ........................................ 18 设计开发阶段 .................................... 19 系统测试阶段 .................................... 21 控制体系 ........................................ 22 用户测试 ........................................ 34

三、 系统整体测试方案 ................................... 35

1.5. 概述 ............................................ 35 1.6. 测试资源和环境 .................................. 35

硬件配置 ........................................ 35 软件配置 ........................................ 35 1.7. 需求分析 ........................................ 36 1.8. 概要设计 ........................................ 36 1.9. 详细设计 ........................................ 36

1.10. 开发........................................... 37 1.11. 集成测试 ....................................... 37 1.12. 系统测试 ....................................... 37 1.13. 验收测试 ....................................... 37

Alpha测试 ...................................... 37 Bate测试 ....................................... 37 1.14. 开发周期所需要产生的文档 ....................... 37 1.15. 软件测试类型 ................................... 39

白盒测试 ........................................ 39 静态白盒测试 .................................... 39 动态白盒测试 .................................... 40 1.16. 功能测试 ....................................... 40 1.17. UI测试 ........................................ 40 1.18. 性能测试 ....................................... 41

负载测试 ........................................ 41 强度测试 ........................................ 41 容量测试 ........................................ 41 系统资源竞争测试 ................................ 42 1.19. 安全性和访问控制测试 ........................... 42

应用程序级别的安全性 ............................ 42 系统级别的安全性 ................................ 42 1.20. 故障转移和恢复测试 ............................. 42

1.21. 兼容性测试 ..................................... 43

浏览器兼容性 .................................... 43 操作系统兼容性 .................................. 43 硬件兼容性 ...................................... 43 1.22. 安装测试 ....................................... 43 1.23. 分辨率测试 ..................................... 44 1.24. 发布测试 ....................................... 44

说明书测试 ...................................... 44 宣传材料测试 .................................... 44 帮助文件测试 .................................... 44 系统用语 ........................................ 44 文档审核测试 .................................... 44 1.25. 缺陷管理 ....................................... 44

错误跟踪管理系统 ................................ 45 软件错误的状态 .................................. 45 Bug管理的一般流程 ............................... 45 软件错误流程管理要点 ............................ 46 1.26. 环境........................................... 46 四、 项目实施工作方式? .................................. 47

1.27. 沟通方式? ...................................... 47 1.28. 工作流程：? .................................... 47 五、 项目培训 ........................................... 48

1.29. 培训总体目标 ................................... 48 1.30. 用户培训的定义 ................................. 48

项目管理人员培训 ................................ 48 关键用户培训 .................................... 48 培训策略 ........................................ 49 培训方式 ........................................ 49 培训设施 ........................................ 49 1.31. 培训计划 ....................................... 49 （4） 教学资料 .......................................... 50 （5） 培训内容 .......................................... 50 六、 项目的交付与验收（包括阶段性成果） ................. 51

1.32. 准备阶段 ....................... 错误！未定义书签。 1.33. 集成阶段 ....................................... 51 1.34. 上线阶段 ....................................... 52 1.35. 上线后支持阶段 ................................. 54 七、 维护及技术服务 ..................................... 55

1.36. 服务与支持 ..................................... 55

服务理念 ........................................ 55 组织 ............................................ 55 ................................................ 56 1.37. 维护及技术服务承诺 ............................. 59

项目建设阶段实施组织方案

项目实施方案是本公司中标后在签订合同后所进行的、并对标的软件需求分析、开发、交付、验收的一系统活动所遵行的工作项目、内容、人员、时间节点以及组织形式等实施预案，在中标后，本公司承诺将按照不低于实施方案的工作标准对标的项目进行实施。

一、项目实施总体目标

1、 研发标的物软件产品三套，并提供Linux操作系统服务器版2

套

序号 1 2 3 4 名称 类型 数量 备注 2、 安装、调测标的物软件产品的运行环境及三套研发成果软件平

台至上线通过采购方验收。

3、 与采购方共同维持测试、试运行及验收 4、 提供三年售后技术服务。

5、 培训采购方管理者、一般用户和技术人员

具体工作内容与方式如下：

二、项目建设阶段实施组织计划

1.1.

项目组织架构

XXXXXXX标的项目实施领导小组 ：

成员包括：XXXXXXX项目总监、XXXXXXX有限公司项目总监。

XXXXXXX有限公司项目小组主要成员情况： 序姓名 号 1 实施组 2 3 4 5 6 7 8 学历 职位 备注 项目领导委员会负责对项目关键事项和重大问题进行议决，听取阶段性汇报，及对项目成果进行最终验收确认。

职责：

 按照实施方案分工界面提供人员、设备、资金支持；

 审查确认项目实施总体计划，确认项目阶段目标的设置，并监督完成情

况；

 参加项目会议，听取每周项目进展汇报；  审阅周工作报告，监督项目进展；  协调解决关键性、全局性问题；

 重大问题、解决方案的决策；  总体验收。

项目经理 建议由一位XXXXXXX的领导和一位XXXXXXX有限公司的资深人员共同担任项目总负责人职务, 分别代表双方管理本项目、负责双方之间的联络，并且在这个合同的所有方面拥有代表本方的权力，并承担相关义务。XXXXXXX有限公司应在星期一到星期五的正常业务时间，即上午 9:00 到下午 6:00（节假日除外）提供本工作说明书项下的服务 他们将负责：

 定义项目管理流程、、和操作规程；  管理项目进程、项目目标、和项目范围；  规划项目总体进程；  项目的全面沟通；

 向项目管理委员会报告项目总体状态。

实施组 实施组由XXXXXXX有限公司实施顾问以及XXXXXXX的系统环境提供单位的关键人员组成，他们将负责：

 针对XXXXXXX的硬件和网络环境条件制定项目实施方案的落

实计划；

 根据系统方案进行系统操作层面的相关配置工作；  完成具体的功能模块实施；  解决最终用户在使用中遇到的问题。

 根据项目需要，安装及维护系统所需的系统环境、开发环境、

网络环境等方面的工作  负责系统的性能调优

 负责项目验收测试，并提交验收报告。

1.2. 实施方案的职责划分

本项目实施是需要XXXXXXX、XXXXXXX有限公司公司两个单位共同努力的，甲乙双方应有明确的分工配合，建立很好的工作机制，才能保证项目成功。

1.2.1. 项目实施过程中

本项目的成功依赖于双方的密切配合和通力合作。在项目实施过程中（包括需求分析、设计、系统安装、系统配置、开发、上线、培训等方面），XXXXXXX、XXXXXXX有限公司公司各自应承担的职责义务： XXXXXXX的职责

 在项目中所需第三方软件（指非标的物供应软件），不通过XXXXXXX有限公司供应的情况下，XXXXXXX将提供软件并提供此类软件的安装、配置和维护工作。  在实施过程中协助XXXXXXX有限公司负责项目管理、环境分析、安装调试及项目系统测试；配合XXXXXXX有限公司进行关键用户培训与知识转移、方案设计。  提供XXXXXXX有限公司完成工作任务所必须的信息  保证与项目有关的问题得到及时解决

 向最终用户说明新系统的功能、用途和业务规范  设置用户权限

 协助制定并执行最终用户培训计划

 与XXXXXXX有限公司共同制定系统测试周期、测试脚本和所需测试业务并共同执行测试

 在XXXXXXX有限公司的协助下，负责初期数据和基础数据的准备和整理工作  与XXXXXXX有限公司共同建立项目环境和项目组织结构

 与XXXXXXX有限公司共同努力，在保证实施质量的前提下，控制项目实施时间进度按时完成工程。 XXXXXXX有限公司的职责

 负责按照本方案确定的实施范围，组织项目的实施工作，确保实施质量并解决或协调解决实施过程中遇到的问题。

 在项目实施必要阶段增加必要资源支持项目成功

 在实施过程中在XXXXXXX协助下负责项目管理、环境搭建及项目系统测试；在XXXXXXX的配合下负责关键用户培训与知识转移。

 指导与帮助XXXXXXX人员进行数据准备及输入。

 负责对于XXXXXXX项目组成员进行系统配置、二次开发、系统维护方面的培训，以使XXXXXXX项目组成员在项目实施完成后能够操作、二次开发、维护、系统配置方面的工作。

 使与项目有关的问题得到及时解决

 提供有关系统在实施范围内的技能和以往的经验  解决系统培训和实施中出现的问题

 计划、协调与项目实施相关的各个方面的工作  与XXXXXXX共同建立项目环境和项目组织结构

 依据项目计划充分调动XXXXXXX有限公司资源，并做好这些资源的后勤保障，在必要时候，寻求公司更高层次的支持

 与XXXXXXX共同努力，在确保实施质量的前提下，控制项目实施时间进度按时完成工程。

 提供必要的原厂技术支持

 提供必要的工信部软件与集成电路促进中心的授牌共建支持。

1.2.2. 上线后的运行维护阶段

在本阶段，XXXXXXX的系统已经运行了一段时间，可能提出对系统的配置和一些新的要求。对于在项目实施过程中由于时间和资源没有全部完成的实施内容也在完善阶段进行补充。同时对用户的使用进行支持。此次项目中系统上线后的试运行定为两个月。 XXXXXXX的职责

 XXXXXXX项目负责人应依据项目需求召开项目管理会议。  保证系统上线后的稳定性

 安排支持人员，解决上线运用中最终用户出现的问题。

 系统维护人员，根据项目设计的流程维护上线后的投产环境，例如维护用户权限等，保证系统安全

 维护问题日志，关于软件问题应敦促软件提供商及时解决 XXXXXXX有限公司的职责

 与XXXXXXX项目经理依据项目需求召开项目管理会议。

 协助XXXXXXX项目经理监督软件商对问题解决的进度。  评估各模块的运行情况，解决系统操作，运用的问题。  继续实施在项目上线前没有完成的实施任务  提出系统配置改进建议  帮助XXXXXXX完善系统运作。

1.3. 项目概要实施计划

项目 一、项目启动 1、项目组织、人员准备 2、测试、开发环境搭建 3、业务系统了解、学习 项目组织机构 项目启动任务书 项目综合实施计划 成果物与说明 天数 参与人员 二、需求分析与技术方案确定 1、数据库、中间件等平台技术构筑方案系统平台构筑优化方案 论证与评审 2、应用系统架构方案和功能分析 3、部门节点数据分析、需求分析 应用平台和功能分析书 数据标准与流程设计 Demo原型、开发技术设4、功能分析 计方案 5、技术规范、策略制定 三、系统设计 1、前置库、中心资源数据库设计及管理规范 2、数据质量审核、比对工具与规范 3、元数据管理工具与规范 5、分析专题建设规范 6、数据交换设计、数据存储设计、系统 集成设计 7、权限控制机制 技术实施方案 详细设计报告 系统实施标准规范 8、门户设计 9、数据展现工具与规范 10、应用框架设计（含：工具集成设计） 四、系统开发、测试 详细设计报告 系统技术手册 系统开发代码 操作手册 系统测试报告 五、项目培训 1、系统管理员培训 现场培训、课堂培训 2、开发技术人员培现场培训、课堂培训 训 3、关键用户培训（操课堂培训 作员培训） 六、系统实施与维护服务 1、系统部署、运行与验收 系统试运行报告 系统安装部署 系统试运行 系统验收 2、运行维护服务 免费服务 系统终验报告 运维手册 系统维护报告 1.4. 项目工作阶段和内容 1.4.1. 项目启动

 签订委托开发合同书  提供项目相关的资料与回答承包商的问题联络票上的相关内容  建立项目组织、对项目进行估算、制订相关的计划、系统可行性调查分析、与客户的沟通、技术上的学习培训等准备工作。  成立项目组织，确定包含项目经理、PJL、SPJL、PPQA在内的关键项目团队组织；  定义《项目过程裁剪定义》  完成《项目作业一栏表》  完成《项目综合管理计划》的制定与评估；  确认承包商“项目综合管理计划”  使用《项目风险问题管理表》对识别出的风险进行管理； 1.4.2. 需求分析阶段  协助提供各项资料、数据  业务访谈协调安排  安排需求专家参与本项目需求调研工作（包括：办公业务类专家、门户专家、集成专家和美工等。）  制定及修改需求开发计划；  需求调查  完成和确认《需求调查报告》。  对确认的内容，记入《问题回答管理票》  需求分析  确定技术解决方案及技术架构；  完成《需求分析报告》  建立《需求追踪矩阵》  需求评审  需求确认  需求基线管理  《问题回答管理票》  《需求调查报告》  《需求追踪矩阵》  《需求分析报告》  《项目需求评审报告》  参与正式审查会议、确认《需求分析报告》 1.4.3. 设计开发阶段

安排工程师进行现场设计开发工作，包括：美工、系统设计专家、办公业务开发工程师、门户开发工程师和系统集成工程师。

1.4.3.1. 概要设计

 提供各项资料文件及数据供软件设计用  协助取得数据库规划所必须的各项文件及要求  负责数据的检查工作  参与正式审查会议，确认“概要设计书”  制定概要设计计划  确定系统架构和概要设计准则  概要设计  完成《概要设计书》。  建立《需求追踪矩阵》。  数据库逻辑设计。  评审系统概要设计  确认《概要设计书》  概要设计基线管理  《概要设计准则》  《概要设计书》  《概要设计评审报告》 1.4.3.2. 详细设计

 参与正式审查会议，确认“详细设计文件”  制定详细设计计划  确定详细设计准则  概要设计  完成《概要设计书》。  将详细设计的内容按照其和需求的对应关系填入《需求追踪矩阵》。  评审系统详细设计  确认《详细设计书》  概要设计基线管理  《详细设计准则》  《详细设计书》  《详细设计评审报告》 1.4.3.3. 程序编码

 监控项目开发进度  制定并不断修正编码开发计划  编制《编程规约》  设计程序框架和共通模块  编码实现  代码评审  编码基线管理  编码完成后，源代码、《需求追踪矩阵》纳入基线管理  编码过程中所产生的所有文档 1.4.4. 系统测试阶段

安排专业测试人员进行现场测试，包括用户、页面、功能、压力等方面的测

试。并由工程师对系统进行调整。 1.4.4.1. 分模块测试

 监控项目开发进度  制定模块计划  测试式样书作成  建立测试环境  实施模块测试  测试结果报告/评估  获得测试结果报告  模块测试基线管理 1.4.4.2. 结合测试

 确认“软件整体测试计划”  依据测试报告，确认测试结果  制定整体测试计划  测试式样书作成  建立测试环境  实施整体测试  参加功能示范审查，确认结果  测试结果报告/评估  整体测试基线管理 1.4.5. 质量控制体系

1.4.5.1. 工作文档

我公司有一套规范的作业流程和标准，以下是我公司项目管理中部分工作文档的列表，本项目的开发过程中可以结合具体情况进行适当的修正。 1 011_CN_项目启动规程_项目任项目启动，事业下发项目任务书 务，任命项目经理，PPQMD部指定PPQA。 2 011_CN_项目启动规程_项目组 组织图 3 011_CN_项目启动规程_项目资说明项目人员使用的开发、测试源管理表 的软件、硬件环境。项目服务器的环境等。 4 011_CN_项目启动规程_参加部 门人员一览表 5 008_CN_项目估算规程_项目作列举项目的作业边界，描述项目业一览表 的交付内容和时间。 6 008_CN_项目估算规程_项目过根据公司要求的项目开发章程程裁剪定义 进行裁剪，形成项目执行的流程和规范，指定项目需要执行哪些流程，输出哪些内容的文档、报告等。 7 008_CN_项目估算规程_项目预 算书 8 009_CN_项目计划制定以及修改概要计划是指项目的里程碑时规程_概要(详细)时间计划 间点等，详细计划是指项目实施的时间计划。 9 009_CN_项目计划制定以及修改项目的综合计划，是项目的时间规程_项目计划书 计划、方法、作业标准、需要达到的质量等等。包含项目的各个阶段的子计划。 10 010_CN_风险和问题管理规程_项目的风险问题票，识别到的风项目风险问题管理表 险和发生的问题填写到这里，进行分析、跟踪等。 11 007_CN_项目监控规程_项目跟项目需要监控哪些参数，监控的踪和监控计划 周期，预计参数值。另外设定了这些内容的偏差范围，超出偏差范围需要进行的控制方法。 12 007_CN_项目监控规程_项目周报 13 007_CN_项目监控规程_里程碑里程碑报告，主要是对当前里程工作总结报告 碑进行总结，判断里程碑是否达到了我们设定的目标，是否能够进入下个阶段。 14 007_CN_项目监控规程_项目总 结报告 15 012_CN_项目需求开发规程_系需求规格说明书。 统要件定义书 16 012_CN_项目需求开发规程_需导出的客户的需求，分析、协调、求开发调查报告 精练细化并消除需求间的矛盾，做成以客户的术语或非技术形式表达的《需求调查报告》 17 012_CN_项目需求开发规程_需 求追踪矩阵 18 013_CN_概要设计规程_概要设 计书 19 013_CN_概要设计规程_概要设概要设计准则通常包括：项目概计准则 要设计的方法、项目概要设计所使用的工具、概要设计成果物所使用的部分模板等。 概要设计方针通常包括：方针包括：操作、错误处理、日志、提示信息、异常处理、命名规约等方针。 20 014_CN_详细设计规程_详细设 计书 21 014_CN_详细设计规程_详细设和概要设计准则的要求类似 计准则 22 015_CN_式样理解规程_问题回对需求、设计文档进行理解，以答管理票 达成我们理解的意思和客户的要求是一样的。需求、设计内容写得不明确的时候，需要提问，提问的问题写到这里，进行回答、记录和跟踪。 23 016_CN_编码规程_程序框架设 计书 24 017_CN_单元测试规程_产品缺陷票 25 017_CN_单元测试规程_单元测 试式样书 26 018_CN_项目集成规程_系统联是指产品经过集成、编译等动作动测试报告 后，进行一个验证，以确定接口已经基本正常。在这个基础上，开始进行SI测试等动作。 27 019_CN_结合测试规程_产品缺 陷票 28 019_CN_结合测试规程_结合测 试式样书 29 019_CN_结合测试规程_结合测测试的计划，包括使用的方法，试计划 准入、准出的原则等等。时间计划只是这个计划的一个部分。 30 020_CN_项目验收及交付规程_交付时，制定这个清单，列举交产品交付清单 付的内容，报告当前存在的为解决的问题。 31 020_CN_项目验收及交付规程_现在改称交付管理表，是对交付纳品管理表 的内容设定相关的检查方法和标准，记录检查的状态，交付的部分的质量数据分析。 32 023_CN_项目结束规程_项目个 人总结考评表 33 023_CN_项目结束规程_项目总 结 34 023_CN_项目结束规程_项目结项目经理向事业提交的结项申请 项申请 35 024_CN_项目需求管理以及变更记录需求变更的表，主要是记录管理规程_需求变更管理一览表 变更的需求和设计等内容，我们当前实施的状态，是否需要对应这些变更，对应变更需要的工数预算，相关的对应计划。 36 024_CN_项目需求管理以及变更 管理规程_需求追踪矩阵 37 025_CN_评审规程_工作产品各个部分的评审报告都需要参Review票兼评审报告 照这个模板填写。 正式评审，发的评审通知。 38 025_CN_评审规程_评审通知 39 026_CN_接收物验收规程_接受对客户给我们的东西进行验收，物验收报告 确认是否达到我们执行项目的需要，或者确认是否达到我们与客户预定的要求。 40 027_CN_度量与分析规程_人力项目经理填写的，项目的每个人资源管理表 员在什么时候以什么角色参加什么部分的工作。 41 027_CN_度量与分析规程_工作- 产品管理表 42 027_CN_度量与分析规程_工作度量项目的投入工作量 量度量分析管理表 43 027_CN_度量与分析规程_度量各个度量分析表中已经有相关分析报告 的度量分析报告信息，在需要时，将这些信息抽取到这个报告中。 44 027_CN_度量与分析规程_度量 计划 45 027_CN_度量与分析规程_成本- 度量分析管理表 46 027_CN_度量与分析规程_生产 率度量分析管理表 47 027_CN_度量与分析规程_缺陷Bug的统计分析表，将Bug管理统计 系统中的Bug导出，用透视图生成分析表格，主要是对Bug进行分类分析。 48 027_CN_度量与分析规程_规模 度量分析管理表 49 027_CN_度量与分析规程_评审统计评审发现的问题数，以及投集计表 入的工作量。 度量分析管理表 50 027_CN_度量与分析规程_质量51 027_CN_度量与分析规程_进度 度量分析管理表 52 028_CN_配置管理规程_创建基创建基线时，提出的申请，主要线申请票 用作申请和CCB对变更的审核。 53 028_CN_配置管理规程_变更基变更基线时，提出的申请，主要线申请票 用作申请和CCB对变更的审核。 54 028_CN_配置管理规程_基线管记录基线的文件内容、路径、状理表 态、变更时间等等。 55 028_CN_配置管理规程_配置审配置审计的物理审计报告，主要计报告 是审计配置项是否按照配置计划纳入到配置库相关的位置，是否按照命名规则进行配置管理。 56 028_CN_配置管理规程_配置管列举配置管理的执行角色即配理计划 置管理组成员、配置控制委员会(CCB)的成员，以及配置库的CVS配置，文件服务器的使用要求，配置项的位置、权限等等。 57 029_CN_决策分析规程_问题决对重大问题进行决策分析(DAR)策报告 时的报告，报告主要有备选方案，决策的依据、标准、方法、评价方法、评价结果、存在风险等。 58 030_CN_过程监控与质量保证规PPQA开出的NC问题列表，以及程_不一致问题票 处理情况的跟踪。 59 030_CN_过程监控与质量保证规PPQA的审核报告，分为阶段审程项目_PPQA报告 核报告和周期审核报告。 程_项_PPQA计划 60 030_CN_过程监控与质量保证规1.4.5.2. 开发品质标准

为确保项目开发的质量，公司对提出了下列基本度量指标。根据项目的具体情况，标准与度量可以派生出更多的度量控制KPI，以保证本项目的实施。

1.4.5.3. 测试密度与bug检出率

工程 单元测试 要素 试验密度 Bug检出密度 下限 65 3 16 0.74 4 0.19 目标 105 6 39 2.2 15 0.74 上限 170 9 92 3.6 50 1.35 结合测试试验密度 1 Bug检出密度 结合测试试验密度 2 说明：

Bug检出密度  测试密度(测试密度是用来衡量测试用例的覆盖度的指标)  测试密度＝ Bug密度＝ 有效源代码：

 项目程序中除注释和空白行之外的源代码，以文件为单位按物理行计算。包含新规源代码、修改的源代码和自动生成的源代码。  正规化源代码行数 

正规化源代码行数＝新规源代码修改源代码＋自动生成源代码10%

总Case个数正规化SOURC行数/1000 总Bug个数正规化SOURC行数/1000

 新规源代码

 手工新制作的程序源代码，不包括测试代码。  自动生成源代码

 由编程工具自动生成的代码。

1.4.5.4. 问题处置能力标准

 联络应对标准

 计算公式：响应日时-收到日时。

 联络：包括客户提出的式样联络、BUG票、和要求变更。  联络响应期间：1个工作日内。  BUG票应对标准



 QA缺陷(NC)票应对标准



1.4.5.5. 评审能力标准

以下时间均指初次评审所必需的经过时间，如需要再次评审，追加投入的时间可递减。但总合计值不应超过2倍。 1) 设计文档评审时间标准单位为(分钟/P)。 2) 源代码评审时间标准单位为(分钟/KL)。 3) Case评审时间标准单位为(分钟/个(Case个数)) 文档类型 审查 小组评审 走查 桌查 文档类型 BD-SPEC DD-SPEC PG-SOURCE① PG-SOURCE② SI1-CASE SI2-CASE 审查 5～7 5～7 40～60 小组评审 走查 3～5 3～5 30～40 3～5 3～5 30～50 桌查 5～6 5～6 40～60 600～720 10～15 15～20 600～720 450～570 - 10～15 15～20 8～10 10～13 8～12 10～15 说明1：审查和小组评审的会议前准备时间未计在内。 说明2：

PG-SOURCE①指侧重于程序结构、规范性的代码评审。

PG-SOURCE②指侧重于查找程序逻辑缺陷的代码评

审。

1.4.5.6. 任务完成度的进度率标准

比率 BD/DD 10% 理解完 正在制作设计书 25% PG 理解完了 编码框架设计完成 UT - SI1/SI2 理解完了 白盒测试CASE设计完成测试CASE和数据制作中 (评审通过) 符合模板要求的设计书按照Coding规约编码完一个回合的测试完毕，达CASE及数据设计完成(评50% 完成 毕(编译通过) 到预定的覆盖率 审通过) 一个回合测试完毕，BUG对应中 内部评审完毕，正在解决DEBUG+源代码评审完毕，BUG对应及复测中 75% 评审问题 正在解决评审问题 评审发现的问题全部解评审发现的问题全部解BUG全部对应且新版本确BUG全部对应且新版本确95% 决 决 认完毕 认完毕 比率 BD/DD 100% 直接管理者承认 PG 直接管理者承认 UT 直接管理者承认 SI1/SI2 直接管理者承认 说明：该指标规定了实施计划中任务的完成度和进度率的对应关系。

无相关对应任务时可跳过该进度率。

1.4.5.7. 正规化编程生产性标准

Java类型项目：

 详细设计-SI1：1200行/人月。  CD+UT：2000行/人月。 1.4.6. 系统交付与用户测试

有系统用户对系统进行测试，根据测试情况，对系统进行完善和调试，项目组安排工程师对系统进行调整。  提供安装场地及必要设施  指派人员点收软硬件设备及文件，并进行安装后测试  确认“系统测试计划”  指派专人协调配合测试  依据“系统测试报告”确认系统结合测试结果  申请交付(包括阶段性的交付时间点与最终交付日期)  准备交付用户测试  确认《交付清单》(一般由客户提供)  确定当前可交付工作产品版本号，分模块制定《020_CN_项目验收及交付规程_纳品管理表》，提出明确的交付内容、提交条件和完成标准。  并标记尚未解决的缺陷和尚未实现的机能  打包交付的工作产品，并测试打包后的产品的可操作性  提供场地及机房设备之安装建议  进行现场系统安装  撰写“系统测试计划”及进行系统测试内容步骤的设计  依“系统测试计划”和测试要求进行系统测试，并撰写测试报告 三、系统整体测试方案

1.5.

概述

系统测试是关注系统的外部特性。它的主要对象是进行系统测试的测试工程师。该方案所包含的测试用例范围包括MicroMOe系统的所有功能测试用例、环境测试用例、性能测试用例以及UI测试用例等。

1.6. 测试资源和环境 1.6.1. 硬件配置 关键项 数量 4 性能要求 期望到位阶段 测试PC机 P4，主频2.6GHZ，硬盘需求分析阶段 300G，内存2G，此配置是实际用机 数据库服务器 1 P4，主频2.6GHZ，硬盘需求分析阶段 300G，内存2G，此配置是实际用机 1.6.2. 软件配置

资源名称/类型 配置 数据库管理系统 操作系统 客户端前端展示 负载性能测试工具 功能性测试工具 1.7.

Oracle、 Centos?服务器版?位 IE9.0 Vs2008； MANUAL 需求分析

需求分析期间，测试的主要工作为：

审核需求分析报告：需求中是否存在不合理现象；需求是否可以被实现 召开需求评审会议：评审会议项目经理，系统分析师，用户代表，客户，测试设计师参加

书写验收测试计划。

1.8. 概要设计

概要设计期间，测试的主要工作为：

审核概要设计报告：概要设计是否符合全部需求，概要设计是否存在问题 召开概要设计评审会议：由项目经理，系统分析师，系统设计师，设计师，测试设计师,技术专家参加。

书写系统测试计划。

1.9. 详细设计

详细设计期间，测试的主要工作为

审核详细设计报告：详细设计是否符合全部需求，详细设计是否存在问题 召开详细设计评审会议：由项目经理，系统设计师，设计师，编码人员，测

试设计师参加

书写集成测试计划。

1.10. 开发

开发期间测试主要工作为

召开开发指南评审会议：由项目经理，设计师，开发员参加书写个阶段测试用例。

召开测试用例评审会议：由项目经理，测试设计师，测试工程师参加设计（由测试设计师设计）并书写测试脚本（由开发人员书写）。

开发后期，由开发人员对开发的模块进行单元测试。

1.11. 集成测试

按照模块上下集关系，进行从上到下或者从下到上的集成测试方法进行集成

测试，单元测试与集成测试主要考虑功能性测试。同时也要对模个模块或者集成模块进行非功能性的抽样测试。

1.12.

系统测试

对整合系统进行整合测试，这时的测试主要测试系统的整体功能和全部非功

能性的需求。

1.13. 验收测试

验收测试首先进行正规性的测试，即由技术人员模拟各户环境，以用户的身

份进行安装和测试工作。然后进行非正规测试alpha测试和bate测试。

1.13.1. Alpha测试

由公司内部开发人员模拟用户进行测试，这个时候还允许对需求做些修改工作

1.13.2. Bate测试

alpha测试后将产品提交给某些特定用户，进行测试，注意这是的软件一定要有使用时间 ，这时候冻结系统需求

1.14.

开发周期所需要产生的文档

立项前期 项目合同 可行性分析报告 项目计划书 需求分析期 需求规格说明书 需求规格审核报告 需求规格评审报告 验收测试计划书 概要设计期 概要设计书 概要设计审核报告 概要设计评审报告 系统测试计划书 详细设计期 数据库设计 详细设计书 详细设计审核报告 详细设计评审报告 集成测试计划书 编码前期 编码规范 编码 测试脚本 测试用例 测试脚本设计书 编码后期 单元测试报告 集成测试报告 系统测试报告 验收测试报告 测试总结报告（决定产品是否可以发布） 集成测试期 系统测试期 验收测试期 后期 使用手册 配置指南 广告材料 蓝色为可选项 1.15.

软件测试类型

软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的一些类型。

1.15.1. 白盒测试

白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开

发工具中的单步调试来判断软件的质量，一般白盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试

1.15.2. 静态白盒测试

利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书

写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下： Function NameGet(){ …. }

这是属于不符合开发规范的。 有这样一段代码: if ((i<0) & (i>=0)) …

这段代码交集为整个数轴，IF语句没有必要 I=0;

while(I>100){ J=J+100; T=J*PI; }

在循环体内没有I的增加, 错误产生。

1.15.3. 动态白盒测试

利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4

组不同的测试数据使4组分支都可以走通而且结果必须正确。 if(I<0){ P1 }else{ P2 }

在调试中输入I=-1,测试P1程序段通过; 再输入I=1, 测试P2程序段，这样的测试属于动态白盒测试的缺陷。白盒测试通常在单元测试的时候进行。

1.16. 功能测试

功能测试指测试软件各个功能模块是否正确，逻辑是否正确。对测试对象

的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI)或者测试脚本与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。

1.17. UI测试

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美

工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等 用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关。

比如：页面基调颜色刺眼；文字中出现错别字；页面显示范围超过屏幕范围等都属于UI测试中的缺陷。

1.18. 性能测试

性能测试主要测试软件测试的性能，包括负载测试，强度测试，容量测试，

基准测试以及基准测试

1.18.1. 负载测试

负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。 比如，用户并发量测试就是属于负载测试的用户，可以使用测试工具，模拟上百人客户同时访问，看系统响应时间，处理速度如何？

1.18.2. 强度测试

强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情

况。这类测试往往可以书写系统要求的软硬件水平要求。主要测试对象为低CPU主频，低存储空间（内存或外存），低连接速度。

实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。

1.18.3. 容量测试

容量测试指通过代码往存储空间中插入一定数量的数据，看看相关程序是

否能够正常运行。

容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，通过编写代码项存贮空间输入一定数量的记录，然后运行需要使用这个存储空间的程序，判断程序是否运行正常。

1.18.4. 系统资源竞争测试

软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源

的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

1.19. 安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面： 应用程序级别的安全性，包括对数据或业务功能的访问 系统级别的安全性，包括对系统的登录或远程访问。

1.19.1. 应用程序级别的安全性

可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者

只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息，而“用户二”只能看见同一客户的统计数据。 比如不通过登入页面，直接进入系统？

1.19.2. 系统级别的安全性

可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相

应的网关来访问。

比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

1.20. 故障转移和恢复测试

故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正

常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。

故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。

故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。

恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份。

比如突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？

1.21. 兼容性测试

又叫配置测试。兼容性测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）

1.21.1. 浏览器兼容性

测试软件在不同产商的浏览器下是否能够正确显示与运行； 比如测试IE，Natscape浏览器下是否可以运行这套软件？

1.21.2. 操作系统兼容性

测试软件在不同操作系统下是否能够正确显示与运行；

比如测试WINDOWS XP,WINDOWS 7,LINU, UNIX下是否可以运行这套软件？

1.21.3. 硬件兼容性

测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用. 比如在不同厂商的CPU芯片下系统是否能够正常运行？ 这样的测试必须建立测试实验室，在各种环境下进行测试。

1.22. 安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的

不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件

在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。 安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

1.23. 分辨率测试

测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*8，

1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

1.24. 发布测试

主要在系统中发布通知文件，比如通知，公告，新闻等进行测试

1.24.1. 说明书测试

主要为语言检查，功能检查，图片检查

语言检查：检查说明书语言是否正确，用词是否易于理解； 功能检查：功能是否描述完全，或者描述了并没有的功能等； 图片检查:：检查图片是否正确 1.24.2. 宣传材料测试

主要测试系统中的附带材料中的语言，描述功能，图片

1.24.3. 帮助文件测试

帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。

1.24.4. 系统用语

产品出公司前的材料文字，功能，图片，人性化的检查

1.24.5. 文档审核测试

文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。

1.25. 缺陷管理

软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中

发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过

程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。

1.25.1. 错误跟踪管理系统

为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。

作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。

1.25.2. 软件错误的状态

新信息(New)：测试中新报告的软件缺陷； 打开 (Open)：被确认并分配给相关开发人员处理； 修正(Fixed)：开发人员已完成修正，等待测试人员验证； 拒绝(Declined):拒绝修改缺陷；

延期(Deferred): 不在当前版本修复的错误，下一版修复 关闭(Closed)：错误已被修复；

1.25.3. Bug管理的一般流程

测试人员提交新的Bug入库，错误状态为New。高级测试人员验证错误，如

果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不

能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

1.25.4. 软件错误流程管理要点

为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

1.26. 环境

为了保证软件版本的控制，需要建立三个环境，开发环境，测试环境以及发布环境

开发环境 测试环境 发布环境 开发环境: 软件产品开发工作所用的环境 测试环境：软件测试工作所用的环境 发布环境：软件发布运行的环境 软件在各个环境中的迁移：

1．当软件经过开发完毕，将软件产品移植到测试环境进行测试，这样测试和开发工作可以相互，互不影响；

2．当软件测试完成发现错误，开发人员在开发环境中修改错误，修改好后，打成数据包，传输到测试环境进行回归测试；

3．当软件决定发布时，将软件从测试环境移植到发布环境，供用户使用 开发环境与测试环境的好处是使开发工作与测试工作相互互不影响。 测试，开发环境与发布环境的好处是使研发工作与用户使用相互。

四、项目实施工作方式?

1.27.

沟通方式?

1.项目经理在每周一上午提交项目周报给：? 项目组长?项目总监；?项目成员；? 2.每周一次项目进度审核会议（周）：? 会议主持：项目经理?

主要参加人员：项目总监、系统实施组?时间：每周五下午? 会议内容：对上周项目过程回顾及对下周项目计划的讨论和确定 3.可根据需要，不定期举行上述会议。?

会议结束后应提交《项目进度审核会议纪要》，内容要包括如下几方面：? （1）任务的当前状况（人员、进度等）；? （2）对以前明确的问题的解决进展；? （3）自上次以来的问题或潜在的问题；? （4）计划纠正措施；?

（5）下一报告期内预期实现的里程碑。

1.28. 工作流程：?

1.根据实施计划、实施方案与前期项目准备工作计划制定月工作计划；? 2.根据月工作计划制定周明细工作计划；（工作任务书）? 3.将本周工作计划用邮件系统分发项目组全体人员；?

4.项目组工作人员根据工作计划开展工作并提交工作成果到双方项目经理处； 5.双方项目经理及时了解工作完成情况并共同讨论是否调整下一步工作计划；? 6.每周五下午双方项目组召开会议，检查本周工作完成情况并制定下周工作计划；?

7.每周一用邮件形式通知项目领导小组项目工作计划的执行情况与本周工作计划；?

8.当项目出现比较重大的特殊情况时，可不定期的召开项目领导小组会议，协商解决方案

五、项目培训

1.29.

培训总体目标

如何做好学习、培训及知识转移工作，是XXXXXXX、XXXXXXX有限公司和产品供应方需要解决的重要课题。

基于XXXXXXX有限公司的诸多大型实施项目中积累的经验，并结合XXXXXXX的实际状况，将保证如下的用户培训目标：

 培训XXXXXXX的关键用户（包括项目管理人员），使其掌握系统的核心功能以及项目实施方法和步骤，具备配合实施顾问推进项目，以及系统上线、XXXXXXX有限公司顾问离开现场后承担维护、支持的能力；

 培养XXXXXXX的IT人员，使其掌握日常运行和维护系统的技能， 包括故障排除、寻求供应商支持等；

 提供有效的、全面的和标准的文档给最终用户，成为其后续稳定应用的保障。

1.30. 用户培训的定义

XXXXXXX的用户培训包括系统维护培训、关键用户培训

1.30.1. 项目管理人员培训

旨在向XXXXXXX的项目管理人员传授系统维护方法和技能

主要培训内容:  系统维护培训  系统配置培训

1.30.2. 关键用户培训

对专职项目小组成员、关键用户提供产品安装、运营管理、功能介绍、和开发工具等的培训。

主要培训内容:

 标准产品功能介绍（标准产品的培训由XXXXXXX有限公司公司提供）  实施方法的培训

 结合XXXXXXX项目的相关应用产品、开发工具培训

1.30.3. 培训策略

为保证在短期内将各种知识和技能传授给不同层面的众多项目参与者，我们建议如下培训策略：

 项目经理、项目小组成员和关键用户的培训集中在项目实施办公室进行  培训时间定为10天。

1.30.4. 培训方式

为确保成功的技能转移，我们将采用如下几种方式：  课堂培训

针对各种专题开设培训课程，如项目管理、实施方法及各模块核心功能介

绍等，通常安排在相关任务开始之初，以使各参与人员能具备完成相关任务的基本技能。课堂培训由培训顾问实施。  交付文档

项目实施过程中交付的一系列文档也是技能转移必不可少的媒体。这些文

档可作为日后进一步培训、推广或联合工作小组的重要参考。为确保项目成果存档，并为今后XXXXXXX后续自我支持提供模板。

1.30.5. 培训设施

由于XXXXXXX有限公司 提供的项目培训是以咨询的方式进行，XXXXXXX应提供必要的培训设施和设备（或由项目合同中指定的项目工作场地和测试、培训设备提供方提供），包括：

 配置台式电脑、网络连接和投影仪的培训教室  小组讨论的的会议室

1.31. 培训计划

此次工程建设是一个系统工程，项目建设实施结束后，要把系统的使用与运营移交给XXXXXXX技术部门。为使系统顺利移交和稳定运行，我公司将完善两方面的工作：其一系统售后技术支持和服务；其二就是本章所要讲述的系统培训。?培训在科技高速发展的当今时代具有巨大的意义，能够改善我们的知识结构，增加我们的技能。系统、细致、全面的培训会把信息化管理

带入一个历史性的时代。根据我公司的项目实施经验和此次工程的总体方案，系统培训分为两个主要阶段：

一 项目实施过程中的现场培训

参与者是客户方参加项目实施的运营管理人员。 二 课堂培训

参与者是XXXXXXX终端操作人员。从系统培训的过程和方法上将，针对此次工程的培训又有其特色，可以定制培训及应用培训。? 合作期间，将为用户提供首次标的产品技术培训。

我公司根据不同培训内容，选派不同培训授课人员，培训教师具有丰富的相同课程教学经验。所有的培训教员都用中文普通话授课。 （1） 培训时间

培训工作必须在系统整体验收之前安排，具体时间由项目采购人指定。 （2） 培训方式

根据用户要求集中进行推广培训。

（3） 培训对象

培训石景山区信息中心技术维护人员、相关委办局操作人员，主要采用集中培训的方式。 （4） 教学资料

服务概述：

合作期间，我公司应完成平台培训手册及相关操作、安装文档、系统维护手册等文档的编写，我公司承诺为所有被培训人员提供培训用文字资料、讲义和课件等，所有的培训资料都是中文书写。

服务内容：

操作手册、安装文档、系统维护手册、教学课件PPT （5） 培训内容

培训内容应包括但不限于系统的功能、安装、运行管理、维护、操作以及

开发工具的使用等。 （6）培训效果

通过培训，应使技术维护人员能够独自进行系统安装、调试、设置、日常维护等管理工作，可自行设定、维护工作流程，可管理人员、权限等信息，可自行判断和解决一些简单问题，能够处理简单的突发事件并进行系统恢复，掌握一般的系统监控方法，将错误现象能够及时准确地反馈给技术支持人员；使各相关委办局及街道操作人员能够完成公文流转全过程的业务操作；部门管理员能够管理本部门各类信息。

六、项目的交付与验收

1.32.

集成阶段

该阶段将完成系统各部分包括从系统设置、安全设置、到用户流程文件的集成，完成向正式应用环境转移。作为切换计划的一部分，在最终用户培训手册的基础上实施最终用户培训。

系统各部分的最终设计和集成的正确性、完整性、稳定性将由用户接受性测试验证，验证测试的测试环境中的数据将应用实际转换的真正静态数据以保证验证的真实性。如有需求，将通过系统性能测试来确定系统的性能能支持正式环境的运作。作为本阶段结束的“上线”准备检查确保“上线”各项准备工作均已准备完毕、系统各部分均处于可运作状态。

用户业务流程作业指南的设计和编写及最终用户培训手册的编写也将在该阶段中完成。

解决的关键问题 确保系统可以稳定转移到正式环境 安全和控制 系统功能的最终用户测试的成功 确认最终系统功能已完成和得到批准 关键用户培训 系统集成测试 规划如何从测试环境切换至正式环境业务操作指南（由用户接受测试 用户权限及安全设置标准 用户接受测试脚本 关键项目任务 移交正式产品环境 主要项目交付成果 关键用户培训 解决的关键问题 正式环境的静态数据的正确性保证和优化 关键项目任务 的计划。 主要项目交付成果 XXXXXXX有限公司顾问指导XXXXXXX关键用户编写） 用户培训手册（由XXXXXXX有限公司顾问指导XXXXXXX关键用户编写） 完成标志：  验收签署

XXXXXXX收到XXXXXXX有限公司交付的上述文件后，应于五个工作日内提出要求修改的书面要求以及修改意见，若逾期，上述文件则被视作已通过XXXXXXX验收。在XXXXXXX有限公司完成了针对修改意见的更改并得到XXXXXXX项目经理确认后，应视本交付件被确认，其中新修改意见提出不可超过两轮，每轮意见提出时间不超过5个工作日。

1.33. 上线阶段

在该阶段，系统各部分将组合成正式的应用系统，并在确认所有系统转换及跟踪维护的职责都已明确、在所有项目任务都已完成的基础上实施系统上线计划，系统上线包括实施动态数据转换、验证已转换数据的正确性、启动新系统。

解决的关键问题 验证所有的工作都已完成且已准备就绪 系统转换责任都已指关键项目任务 执行系统切换：所有实施工作完成以后，执行系统切换，开始应用新系统运作正常主要项目交付成果 系统切换完成报告 解决的关键问题 定 系统维护任务都已落实 关键项目任务 的业务处理， 实施后支持 确保系统数据准确。对主要项目交付成果 正式环境已准备就绪 实施数据转换的及时完成和成功 系统的应用 于由于系统转换所带来的变化作进一步的变革管理，对系统运行的绩效作进一步优化。 完成标志：  验收签署报告

XXXXXXX收到XXXXXXX有限公司交付的上述文件后，应于五个工作日内提出要求修改的书面要求以及修改意见，若逾期，上述文件则被视作已通过XXXXXXX验收。在XXXXXXX有限公司完成了针对修改意见的更改并得到XXXXXXX项目经理确认后，应视本交付件被确认，其中新修改意见提出不可超过两轮，每轮意见提出时间不超过5个工作日。

在系统上线后一周内，XXXXXXX项目小组需要开始进行验收工作。验收方法按照XXXXXXX要求进行，主要检验系统上线后的稳定性和可靠性。同时，XXXXXXX项目小组需要进行交付件验收。

对于验收中发现的需要改进的问题清单，XXXXXXX项目组应在验收工作开始5工作日内一次提交XXXXXXX有限公司，XXXXXXX有限公司和XXXXXXX将共同协商问题清单的解决方案，在此基础上，XXXXXXX有限公司负责在XXXXXXX的协助下进行系统改进，在系统改进完成后XXXXXXX有限公司会书面通知XXXXXXX，XXXXXXX需要在5个工作日内给予确认或提出不符合问题清单解决方案的地方，如逾期，则视为总体验收通过。当问题清单上问题改进全部被XXXXXXX确认完成，

总体验收完成。

如果总体验收过程中出现下述情况，验收将仍旧被认为是通过的：  应用程序功能完备，但部分使用者感到不习惯

 XXXXXXX自身要求和/或XXXXXXX未能够完成内部变革来实现业务蓝图设计而非系统原因和/或不可抗力使业务蓝图文档中部分设计未能够实现。 以上总体验收工作完成标志项目完成，进入上线后支持阶段。

如果在系统上线一周内XXXXXXX不开始验收工作，项目认为被总体验收完成，项目结束，进入上线后支持阶段。

1.34. 上线后支持阶段

在本阶段，XXXXXXX的系统已经运行了一段时间，可能提出对系统的配置和一些业务流程新的要求。对于在项目实施过程中由于时间和资源没有全部完成的客户化开发也在完善阶段进行补充。同时对用户的使用进行支持。

上线后支持阶段为系统上线后一年。 解决的关键问题 评估新的系统运行的状况和改进方案 总结推广模板 关键项目任务 评估各模块的运行情况，解决系统操作，运用的问题。 提出系统配置和业务流程改进机会 帮助XXXXXXX完善 项目完结报告 主要项目交付成果 系统配置改进建议 完成标志：

 验收签署的项目完结报告。

XXXXXXX收到XXXXXXX有限公司交付的上述文件后，应于五个工作日内提出要求修改的书面要求以及修改意见，若逾期，上述文件则被视作已通过XXXXXXX验收。在XXXXXXX有限公司完成了针对修改意见的更改并得到XXXXXXX项目经理确认后，应视本交付件被确认，其中新修改意见提出不可超过两轮，每轮意见提

出时间不超过5个工作日。

在系统上线后支持阶段时间到期，并且根据以上交付件接受程序，XXXXXXX有限公司所提交交付件通过XXXXXXX验收后，双方应在5个工作日内签署项目完结报告，若逾期，则视为双方已签署项目完结报告。

项目完结报告一旦签署，则标志项目整体结束。

七、维护及技术服务

1.35.

服务与支持

由于我公司的实施过程中注重知识的有效转移给用户，同时加强对用户的培训，在项目实施完成后，用户能对系统进行日常维护和一些简单的深化。综合各项因素，和其它系统公司相比，我公司在维护年费收取上也是比较低廉的。我公司，能及时的对用户的维护需求、售后服务和技术支持作出响应，及时上门服务。

1.35.1. 服务理念

 服务宗旨：以客户为中心，全面满足客户需求  服务目标：顾客满意度最高 1.35.2. 服务组织

成立的客户服务部门为客户提供系统化、专业化的系统维护服务。我们秉承耐心、细致、专业、高效的客户服务理念，多年来为保障客户软件系统上线前后的稳定、持续运行做出了不懈的努力。

 项目领导小组：

由双方高层或指定人员组成领导小组，协调和决策维护期间的重大事件。

 用户方工作组：

a) 负责向维护组长开出系统问题票，并在维护组对应完成后进行检收； b) 同时，对于一些可能的需求变更意向，收集整理并提出变更需求，

评审需求变更设计，检收程序

 服务商维护组组长：

a) 接收问题票，并对问题票的类型(BUG，需求变更，咨询，数据修补

等)进行判断 b) 诊断分析问题原因

c) 并计算判别计划对应时间，制定对应计划，分发工作 d) 控制对应进度，保证维护质量

e) 对于需求变更类问题票，负责需求的调研和设计 f) 负责与客户之间的沟通和协调  服务商维护组人员：

按时保质保量完成维护组长分发的任务  服务商维护热备组：

该维护组作为专职维护组的一个热备，不隶属于项目组；但需要对所维护的项目的系统架构、业务、数据结构等具有一定程度的了解，以便在一些紧急情况下，帮助专职维护组开展工作，确保和真正实现 7×24小时提供维护服务。

1.35.3. 服务管理

1.35.3.1.

维护流程

 在系统维护期内，对于客户提出各种问题票，登记《日常维护清册》，

如有现场维护团队，则该团队完成这部分工作。  诊断分析问题后，与客户方共同协商确定对应完成时间  根据计划完成时间，编制对应计划，分发给维护人员

 对应完成后，由客户方检收，维护组长在《日常维护清册》中登记

客户检收结果

 维护组长每天负责填写《日常维护清册》，登记维护项目，需求编号，

实际发生工时数，对应状态等

 每周向客户和维护服务部提交维护周报

1.35.3.2.

工作汇报制度

维护组长每周向客户和部门提交项目维护周报，并附本周的维护

清册。并且可以根据客户的要求，按季度或按年，向客户提供季度/年度维护清册。

1.35.3.3.

持续改进提升服务质量

优质的服务依赖于我们不断自我审视和完善服务体系，更依赖于您长久以来的支持和关注，因此，您的每一点建议和评价，是我们持续改进、自我完善、提升服务质量最好的依据。

我们以季度为单位，定期向您发出《客户满意度调查表》，以及相应的电话调查，期望能够收集到您对我们的产品质量、维护服务、管理水平等各个方面的建议和评价。我们将充分研究您的回馈信息，并在内部采取纠正措施以给您及您的公司提供更好的服务。

客户满意度调查表

客户单位名称： 软件项目： 联系人： 联系电话： email: 调查日期： 年 月 对于以下各项陈述，请根据您的体会，在以下各项中给予相应的评价。 □ 1 2 3 4 □ 1 2 3 4 5 6 7 8 □ 1 2 3 产品方面 产品满足需求的能力 产品的质量和可靠性 产品的技术 技术文件的质量 人员方面 人员的现场维护能力 人员的沟通能力 人员的服务态度 人员对技术问题的沟通与跟踪能力 人员对业务问题的沟通与跟踪能力 人员对需求变更和追加的设计能力 人员对问题响应的及时性 人员的技术水平 管理方面 履行进度承诺的及时性 维护的可靠性和及时性； 沟通渠道的畅通性 满分 10 10 5 5 评价 评价 5 5 10 5 10 5 10 5 评价 5 5 5 □ 总体 100 最后，非常感谢您列明对以上问卷未提及项的改进建议和要求： 改进建议 要求 签名： 再次感谢您对我公司的帮助和支持！追求客户满意是我们公司的一贯目标，我们保证将充分研究您的回馈信息，并在内部采取纠正措施以给您及您的公司提供更好的服务。 1.36. 维护及技术服务承诺

 服务方式  现场安装调试服务：

 我们为客户提供免费的现场系统安装和调试服务，保证系统顺利上

线。

 热线电话服务：

 我公司提供热线，我们的技术顾问将通过热线电话及时解答用户提

出的各种问题，帮助用户解决在运行过程中随时出现的各种问题，内容包括：业务及应用支持、系统及性能支持、问题诊断及过程帮助、硬件与数据库支持等。  7×24小时远程技术支持：

 设立服务热线(固定电话和移动电话)，由一名工程师负责组织和协

调用户的系统维护工作，保证客户在7×24小时内都能得到服务响应，对于用户方软件系统发生的一切问题，这名工程师都将负责安排帮助解决。  现场技术服务：

 对于电话等远程技术支持手段不能解决的问题，提供现场技术服

务。

 对于危机运行的重大问题和系统不能正常运行的的特大问题，提供

现场技术服务。  定期上门服务：

 每月定期提供上门系统维护服务，帮助客户及时发现系统故障隐

患，了解用户反馈和要求，并可使用户及时了解最新产品消息，取得最新代码，以及最新开发、修改后的工具包程序。  后续开发服务：

 在质保期内应根据客户的需要，我们将派遣技术支持人员，为系统

将来的升级和扩展应用，提供必要的帮助。

 服务响应时间 提供本地化的技术支持服务，运行中出现故障时，我方依据接收到的维护通知，对各类问题进行及时的服务响应：  疑难问题（不危及运行）  在24小时内答复用户。  重大问题（危及运行）

 在2小时内到现场处理或通过网络远程处理。  特大问题（系统不能正常运行）

 在2小时内恢复系统运行，并在24小时内派技术人员到现场解决。  质保期限 本项目产品质量保证期为三年，自项目验收合格后计算。

质量保证期内，负责免费对运行中出现的故障进行解决，提供系统的维护服务。（包括免费的系统升级及其后续服务等内容）  免费服务期后的服务

为客户提供两种收费服务方式：一种为按实际工作量计算的服务方式，第二种为按人员核算的服务方式，即客户买断公司维护人员。