1.5.4.4 完成标准
《软件测试报告》审批通过。
1.5.5 集成服务
1.5.5.1 概述
集成包括用户集成、数据集成和数据集成。系统间集成的方式有服务的方式、队列方式、数据库表方式等。本项目的具体集成方式根据XX报社集团的要求来最后确定。
1.5.5.2 集成过程
? 确定集成需求
XX公司项目组和甲方、其他相关应用系统开发商一起，对系统集成需求进行调研，主要从应用系统集成需求、应用集成平台需求和基础支撑环境需求三个角度展开对应用系统集成工作的全面调研，明确系统之间的关联关系，以及应用系统与应用集成平台的关联关系，确认整体集成需求，以更好的开展集成设计工作。
? 执行集成标准
在集成设计时，规范标准很重要。本系统的集成将按照XX报社集团制定的应用集成规范和标准进行门户、应用和数据集成。确保集成的技术先进，灵活可扩展。
? 统一集成设计
有了对需求的全面完成的把握，项目按照SOA架构进行总体设计，并基于构件技术对应用系统进行切分并开发这些构件，最终由总集成商集成在应用集成平台上。 ? 集成测试实施
集成实施阶段首先需要确认集成环境已经准备继续，然后组织集成的相关系
16 / 52
统开发商和业务部门进行集成测试，测试通过进入试运行，试运行期间有问题及时记录、修改并测试验证问题，确保集成顺利实施。
1.5.5.3 交付件
? 《集成设计说明书》 ? 《集成测试报告》
1.5.5.4 完成标准
集成测试实施通过。
1.5.6 施工保证
1.5.6.1 概述
在XX报社集团进行的系统的软、硬件安装调试，以及系统管理员培训、业务操作培训、现场培训、数据初始化和数据导入等工作。XX公司对试运行结果和意见进行汇总，提交系统试运行报告，并请XX报社集团进行审核批示，确定需作改进的问题，交付XX公司进行修改，XX公司根据问题汇总制定修改计划，并按时完成软件更新。
1.5.6.2 系统实施过程
系统实施是一项复杂的工作，需要XX报社集团和XX公司做认真细致的准备。进行软件工程过程中发生的各种软件工程管理活动。实施项目计划，最重要的是遵循计划，并完成相关的工作。 实施过程包括以下步骤：
17 / 52
1.5.6.2.1 设备与系统检测
检查系统所包含的硬件设备和系统软件是否正常。硬件设备有主机、网络、线路和电源；系统软件主要包括操作系统版本、IE版本、数据库系统、应用服务器、Web服务器等。 1.5.6.2.2 安装应用系统
? 安装数据库，进行初始化； ? 安装、配置中间件平台系统； ? 配置HTTP系统； ? 应用软件的安装。 1.5.6.2.3 运行规划与准备
在本阶段对业务流程进行详细划分，确定并安排每个岗位的职责，确定业务过程的衔接，准备操作员信息表，确定每个操作员的岗位；
进行人员的管理咨询培训和上线准备培训。 1.5.6.2.4 基础数据准备与导入
和XX报社集团进行基础数据编码规划探讨，XX报社集团按照基础数据编码规划填写数据准备表；
基础数据准备好后，在系统中录入数据，进行数据初始化。 1.5.6.2.5 测试应用系统
与XX报社集团协商，制定测试计划； 安排所有业务部门，进行测试及操作培训。
18 / 52
1.5.6.3 交付件
系统实施的交付件有《系统实施计划》、《系统管理员手册》、《用户操作手册》。
1.5.6.4 项目施工保证
按项目实施进度计划安排日程，要求所有实施人员掌握整个项目计划，明确每一个实施人员的权利及义务，对实施人员进行产品及技术培训。
实施《实施人员管理计划》，确保所有人员履行所属责任。每天准时到实施地点报到上班，并分配当天工作任务，在当天工作完后对当天的工作进行总结，并计划分配第二天的工作任务。
项目经理及技术骨干每天按项目实施标准及计划，定时巡视实施现场，确保项目进度如期进行及达到实施标准。如实施环境发生特殊情况，立刻通知项目经理，有需要时同时通知用户，以做出适当处理。
实施组每天应归纳工作中出现的所有问题，做出实施进度情况总结报告，并向负责人提交，并做到对文档资料的及时归档、建档。
项目经理批阅每天有关总结报告后，应快速做出回应，根据实际需要调动人员及调整实施计划，以确保项目的质量及进度。
项目组将按照以下两种方式向甲方提交书面项目进度报告： 1、于每月结束后五个工作日内提交；
2、按照约定的项目进度安排，于每一阶段工作完成后五个工作日内提交。 项目进度报告的内容包括：项目进度、已完成的开发项目、本项目的预期效果、人员配置情况，以及其他与本项目有关的甲方应当知道或其要求知道的情况。
系统实施中应注意：
? 坚持质量第一，确保规范实施； ? 按计划和方案组织实施；
? 严格执行标准实施安装程序和制定的相应技术规范和要求；
19 / 52
? 严格按照标准保证项目的质量，确保可靠性，安全性；
? 必须严肃工作纪律，各级实施人员都不得随意更改方案的内容，如因实施条件变化，方案难以执行，或方案内容不切合实际之处，应逐级上报，经变更确认后，方准执行新规定。
1.5.7 试运行与维护
1.5.7.1 概述
1.5.7.2 试运行与维护过程
1.5.7.2.1 模拟运行
初步测试后，业务部门进行并行操作模拟运行，并随时进行比较，确认系统有效。
1.5.7.2.2 正式运行
在确认基础数据正常后，与XX报社集团确定正式运行日期；录入相关单据，初始化系统。
1.5.7.2.3 问题反馈与改进
确定需作改进的问题，交付XX公司进行修改，XX公司根据问题汇总制定修改计划，并按时完成软件更新。 1.5.7.2.4 系统运行维护
系统需求变更或调整，记录变更原因和软件及源代码的版本控制，按照软件变更要求对系统进行维护。
20 / 52
项目实施管理方案
1.1 项目实施与管理目标
一般项目的管理采用目标管理法。项目管理目标主要包括用户满意度、进度、质量、风险、成本五类，当前重点考虑在满足其它管理目标的前提下取得最大用户满意度。
用户满意目标
用户满意是项目管理追求的首要目标，也是其他目标执行的指导原则。 进度控制目标
遵照招标书要求，严格遵守合同规定，不折不扣地按时完成合同规定的所有工程任务。在工程执行过程中出现任何变化，在保障用户利益的前提下，双方磋商、达成一致，确保合同完成，让用户满意。
质量控制目标
质量是工程建设的基石，没有质量其他目标就没有意义。质量控制在项目管理中是极其重要的，通过建立规范的管理体系、严格的内部管理措施、可靠的工程质量保障机制、明确的验收方式、有效的知识转移培训和完备的售后服务措施，确保项目的顺利实施，不会造成任何形式的返工。
风险控制目标
任何事件的发展都会有一定意外，它的发生是不确定的，这种脱离常规的意外称之为风险。风险存在于任何工程建设项目，风险控制是长期、大型项目管理所必需的管理内容。根据以往经验，重视风险要比风险管理本身更重要。风险不可预测，但可以管理与补救。本项目将从风险因素管理、风险预警与应急管理、风险补救三个方面确保项目风险处于管理控制范围之内。
预算控制目标
项目预算控制反映了项目建设的高效性，考核项目预算是自我监督的重要步骤，目的在于提高项目管理水平。控制项目预算的表现在资源调配的合理、高效，重点在于项目规划设计与组织，难点在于对用户需求把握的准确性和设计的合理性、科学性。
1 / 52
我公司目前自行开发的PMS系统作为专业的项目管理工具。通过该工具的各个模块实现对项目的全面管理。
PMS系统能够为项目经理提供如下帮助：
1）为项目分配人员，并为项目人员编制任务计划，同时对于人员的实际工作地点以及工作任务也能够实时进行跟踪和监督，从而实现项目人员的全面监管；项目团队配置情况页面如下图所示：
项目人员分配
2）利用PMS系统可以对每月项目的费用进行预算，并能实时进行计划值与实际值的对比，为项目经理提供决策支持；项目预算配置页面如下图所示：
项目预算管理
3）在项目的实施与运维过程中，它可以对里程碑任务进行跟踪并使里程碑获得财政审批以确认收入，它使得项目经理能够管理项目中的问题和缺陷，它也可以对审查和流程进行跟踪；项目里程碑配置页面如下图所示：
2 / 52
项目里程碑管理
4）它还有助于项目经理加速报告的进程。
1.2 项目组织机构
1.2.1 项目组织架构
本项目的项目组织架构由XX报社项目组和XX公司项目组共同组成，采用项目领导组领导下的各级项目组长负责制，并明确规范所属各组的职责及组间协调关系。这种组织结构是XX公司在多个大型工程项目采用，并被验证为行之有效的工程组织方案。
整体项目的组织结构如下图所示：
整体项目组织结构图
项目管理采用项目组长负责制，形成内部垂直管理体系。各项目小组之间的工作流程和协作关系如下。
3 / 52
? 项目领导小组
负责该项目的统一领导，在实施过程中进行管理，做出重大决策。 ? 项目经理
项目经理是项目的总负责人，对内负责公司内部资源的协调，对外负责与客户的沟通，对项目的决策、需求变更、执行进度等负责。
项目经理是整个项目执行过程中的关键人物，项目经理的更换必须以正式的形式向XX报社项目领导小组申请，在得到批准后方可调换。
? 技术经理
技术经理负责项目的总体设计，指导管理体系梳理、业务架构和技术架构设计、总体技术方案实现以及各地实施方案的设计和评审，指导各小组的设计和开发工作。同时还需要负责技术路线选择、技术架构设计和逻辑结构设计，带领和指导设计团队进行详细的系统设计。
? 需求组
由各模块项目经理及设计师组成，负责进行各模块需求调研，根据调研结果编写需求调研报告。
需求开发组的工作分为两个阶段，第一阶段的任务是框定项目的范围，第二阶段的任务是进行具体的需求调研工作。
需求组需要XX报社集团及其相应部门的相关人员配合。 ? 设计组
负责解决系统建设过程中的各种规划和设计问题：负责编写系统建设方案，负责编写系统安装配置手册，负责制定各阶段验收方案。总体设计组由XX公司的系统设计人员和各方面技术专家组成。
? 开发组
4 / 52
负责进行XX报社集成信息门户项目系统的软件开发，输出源程序、目标程序及用户操作指南。开发组由XX公司各级别软件开发工程师组成。
? 测试组
负责对系统进行内部测试。包括功能测试和性能测试。为了严格把关、提高测试效率，项目组将设立专门的测试岗位，派专人完成软件测试工作。并且，邀请用户方委派代表监督测试工作的执行过程。测试组由XX公司技术负责人、业务负责人和用户方代表组成。
? 实施组
实施组负责XX报社集成信息门户项目操作系统、中间件、数据库如搭建、系统的部署和安装工作，以及相关部署文档的整理工作。
? 培训组
培训组负责三个标段模块的使用、管理和配置的现场和远程培训工作。 培训组成员由实施组和部分开发组成员兼任。 ? 运维服务组
运维服务组负责软件推广实施后的本项目的技术支持与服务工作，提供给用户及时准确的帮助，包括系统的培训、使用方便的热线咨询、现场服务和故障的修复。运维服务组由XX公司技术服务中心工程师和现场工程师组成。
为确保项目的成功完成，包括设计、开发、实施等在内的所有XX公司项目组的技术人员将在项目经理带领下，组成项目的长期服务机构。
? 商务代表
商务代表负责协调项目的合同及相关软硬件厂商的沟通协调。
1.2.1.1 参加本项目人员汇总表
序号 项目组职务 姓名 资格证明 证书名称 5 / 52
级别 证号
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 项目经理 技术经理 高级需求分析师（协同办公） 高级需求设计师（人事薪酬） 中级需求分析师（协同办公） 中级需求设计师（人事薪酬） 高级系统设计师 中级系统设计师 中级系统设计师/数据库设计师 中级系统设计师 高级开发工程师 高级开发工程师 高级开发工程师 高级开发工程师 中级开发工程师 中级开发工程师 中级开发工程师 中级开发工程师 中级开发工程师 测试工程师 测试工程师 实施负责人 实施工程师 实施工程师 1.3 项目实施规划
本项目建设周期为1年，为确保项目实施进度和质量，满足XX报社建设目标，分两组进行并行开发，其中门户和协同办公第一组，人事薪酬第二组。另外，门户和公文管理部分可以在12月份之前快速上线。实施整体规划如下图：
6 / 52
1.4 项目实施计划
招标要求本项目建设周期为1年。XX公司根据1年的建设周期要求提供整体项目实施计划和保障措施，具体实施计划安排如下：（假设本项目于2016年9月10日签订合同）
项目阶段 时间计划 工作内容描述 备注 《项目任务书》《项目 成立项目组，确定工作分工和工1、项目规划 2016/9/10~2016/9/12 作方法 签订项目任务书 制定项目总体计划 二、需求分析 2016/9/16~2016/12/31 搭建试用系统，培训与调研业务流程、管理要求和功能需求 部分界面原型设计、编写《需求规格说明书》 组织需求评审 3、需求评审确认 2016/10/16~2016/10/31 完善《需求规格说明书》，需求签字确认 7 / 52
包括需求调研、需求分析、编写需求规格说明书和需求确认。 第一组：门户和协同办公需求调研及分析（2016/9~2016/10） 1、需求调研 2、需求分析级设计 2016/9/16~2016/9/30 2016/9/16~2016/10/15 总体计划》 成立项目组、对项目范围、目标达成共识、项目启动 《需求规格说明书》 一、项目启动 2016/9/10~2016/9/15
第二组：人事薪酬、集成及广义数据管理需求调研及分析（2016/11~2016/12） 1、需求调研 2、需求分析级设计 2016/11/01~2016/11/31 2016/11/15~2016/12/15 搭建试用系统，培训与调研业务流程、管理要求和功能需求 部分界面原型设计、编写《需求规格说明书》 组织需求评审 3、需求评审确认 2016/12/16~2016/12/31 三、系统设计 2016/10/01~2017/01/31 完善《需求规格说明书》，需求签字确认 系统数据库设计、功能设计、接口设计 组织设计评审 完善《系统设计说明书》 系统数据库设计、功能设计、接口设计 组织设计评审 完善《系统设计说明书》 源代码、《配置管理报告》 系统设计说明书 《系统设计说明书》 第一组：门户和协同办公系统设计（2016/10~2016/11） 1、系统设计 2、设计评审 2016/10/01~2016/10/31 2016/11/01~2016/11/15 第二组：人事薪酬、集成及广义数据管理系统设计（2016/11~2017/01） 1、系统设计 2、设计评审 四、系统开发 2016/11/15~2017/01/15 2017/01/16~2017/01/31 2016/10/15~2017/4/30 第一组：门户和协同办公系统开发（2016/10~2017/02） 1、PC门户 2、移动门户 3、信息门户 4、协同办公应用 2016/10/15~2016/11/15 2016/10/15~2016/11/15 2016/10/15~2016/11/15 2016/11/01~2017/02/28 PC门户开发及单元测试 移动门户开发及单元测试 信息门户开发及单元测试 公文、事务、会议、车辆、办公用品、知识管理、协同管理、各部门其他协同办公开发及单元测试 第二组：人事薪酬、应用集成开发（2016/12~2017/03） 人事档案、稿费核算、薪酬管理、1、人事薪酬应用 2016/12/01~2017/03/15 考勤、合同、社保福利、干部评议、员工绩效考核、党工团管理开发及单元测试 北大方正采编业务系统2.0版、 北大方正采编业务系统二期、金蝶2、应用集成 2017/03/15~2017/03/31 财务系统、审计管理系统、舆情系统、两微端管理系统（包括微博、微视、微信、app客户端）开发及单元测试 3、中经网对接 五、系统测试 2017/03/15~2017/03/31 2016/11/1~2017/03/31 与中国经济网的对接开发及单元测试 8 / 52
源代码和《测试报告》 代码开发及单元测试
第一组：门户和协同办公系统测试（2016/11~2017/02） 1、制定测试计划 2、准备测试环境 3、系统测试 2016/12/1~2016/12/25 2016/12/26~2016/12/31 2017/01/01~2017/02/28 制定 测试计划和测试方案 准备测试环境、测试数据 系统测试、集成测试、性能测试和安全测试 制定 测试计划和测试方案 系统测试、集成测试、性能测试和安全测试 系统安装 1、系统安装调试 2017/04/01~2017/0/15 系统数据初始化 系统调试 七、系统初验 1、验收文档准备 2、系统初验 八、系统上线试运行 1、系统试运行 2017/04/15~2017/04/30 2017/04/16~2017/04/25 2017/04/26~2017/04/30 2017/5/01~2017/7/30 2017/03/16~2017/05/31 准备需求文档、设计文档、测试文档、操作手册等 召开验收会议，签字确认系统初验 用户培训及试运行 问题收集 系统完善和优化 九、系统终验 1、验收文档准备 2、系统终验 十、运维服务 1、系统完善和优化 2、技术支持与服务 2017/08/01~2017/08/31 2017/08/01~2017/08/20 2017/08/21~2017/08/31 2017/09/01~2018/08/31 准备技术文档、需求文档、测试文档等 验收申请、组织验收会和签字确认 根据运行情况进行系统完善和修2017/9/01~2018/08/30 改 技术支持与服务 《服务日志》、《系统运行报告》 验收文档和系统完善 《终验报告》、《终验文档》 《系统运行报告》 验收文档 《安装维护手册》、《系统操作手册》 《安装维护手册》、《系统操作手册》 《系统初验报告》、《初验文档》 包括集成测试、联调测试、压力测试 第二组：人事薪酬、应用集成测试（2016/12~2017/03） 1、制定测试计划 2、系统测试 六、系统安装调试 2016/12/15~2017/01/15 2017/01/16~2017/03/31 2017/04/01~2017/04/15 1.5 软件过程管理
软件过程管理的一方面是提高质量，降低成本；另一方面则是软件的工程化开发提供保障。
根据此项目的特点以及公司CMMI5的管理要求，我们在软件过程管理中将
9 / 52
在软件原型的基础上采用“渐进生命周期模型”，形成合理的过程管理方法。项目的完整生命周期从立项开始到维护期结束，XX报社集成信息门户项目管理过程分为项目调研与需求管理、系统设计、编码开发、软件测试、集成服务、施工保证、试运行与维护等管理。
1.5.1 项目调研与需求管理
1.5.1.1 概述
项目调研是通过调查与分析，获取XX报社集团的需求，了解XX报社集团的组织结构、确定用户并识别部门关键的业务过程与活动、区分过程和活动的优先级、了解部门现有信息系统及运行状况、了解系统功能/性能接口列表等。
需求管理是在XX报社集团与XX公司之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更，实现对需求的确认、跟踪、变更控制等。
1.5.1.2 项目调研与需求管理步骤
? 项目调研过程
通过调查与分析，获取XX报社集团的需求并定义系统需求，包括需求调查、需求分析、需求定义：
需求调查：在XX报社集团进行访谈式和问卷式调研，通过各种途径获取用户的需求信息（原始材料）。在需求调查时，XX公司应做尽可能详细的记录，回公司整理后，发给需求负责人，项目负责人收集所有记录，形成项目整体的需求记录。另在调研时应注重对调查结果进行整理，并对现有业务流程进行整理（形成用例），以确保被调查业务的完整性。
需求分析：对各种需求信息进行分析，消除错误，刻画细节等。 需求定义：根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《系统需求规格说明书》。系统设计人员将依据《系统需求规格说明
10 / 52
书》开展系统设计工作。需求人员要协助测试人员一起制定《系统测试计划》和《系统测试用例》。
? 需求管理过程
项目调研管理包括需求确认、需求跟踪、需求变更控制管理。
需求确认：由XX报社集团和XX公司共同对《系统需求规格说明书》进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求确认包括“需求评审”和“需求承诺”。
需求跟踪：比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保“需求－设计－编程－测试”之间的一致性，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
1.5.1.3 交付件
《系统需求规格说明书》
1.5.1.4 完成标准
《系统需求规格说明书》审批通过。
1.5.2 系统设计
1.5.2.1 概述
系统设计覆盖《系统需求规格说明书》的全部内容，并作为程序开发的依据，使系统能够被软件开发小组顺利地实现。
11 / 52
1.5.2.2 系统设计的步骤
? 概要设计
概要设计注重宏观和框架的设计，包括总体结构设计、全局数据库（包括数据结构设计）、外部接口设计、功能部件分配设计、部件间接口设计，覆盖《系统需求规格说明书》中的功能点列表、性能点列表、接口列表。其过程如下：
其中数据库设计包括数据库需求分析—→数据库概念设计—→数据库物理设计三个阶段，其过程如下：
12 / 52
? 详细设计
详细设计覆盖《系统概要设计说明书》的全部内容，注重微观和框架内的设计，是各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、报表输出模块设计、前台用户界面设计、后台数据处理模块设计、数据传输与接收模块设计等。
在设计阶段后期要重新进行规模、工作量和进度的估算，调整开发计划。进行概要设计的人员要协助测试人员一起制定《系统测试计划》和《系统测试用例》；进行详细设计的人员要制定《系统单元测试计划》和《系统单元测试用例》。
1.5.2.3 交付件
? 《系统概要设计说明书》 ? 《系统详细设计说明书》
1.5.2.4 完成标准
《系统概要设计说明书》和《系统详细设计说明书》审批通过。
1.5.3 编码开发
1.5.3.1 概述
软件实现是通过输入《系统详细设计说明书》，输出源程序、目标程序及用
13 / 52
户指南，此阶段分为编码、代码静态检查和单元测试三个环节：编码人员根据《编码规范》进行编码；代码静态检查对代码的规范符合度进行检查，质量保证人员也要抽查编码规范的遵守情况；单元测试由编码人员根据详细设计阶段制定的测试用例自行或交叉进行，最终形成《单元测试报告》。
1.5.3.2 编码开发的步骤
1、项目组根据概要设计说明书、详细设计说明书制定系统实现计划 2、有条件的情况下保证开发、测试和生产环境独立。选择软件工具，明确项目成员的职责分工，按照编码规范和详细设计实现软件功能。
3、代码应满足结构良好，清晰易读，且与设计一致，符合编码规范。 4、开发人员需要软件实现过程中编写软件功能说明，源代码说明。软件功能说明文档应说明项目名称、编号、软件名称和版本号，软件功能、主要功能实现过程。源代码说明应说明项目编号、软件名称、功能，全局变量、数据库字典、函数功能、接口。该文档包含在源代码文件中，以注释形式存在。
5、项目组进行单元测试和集成测试。开发人员处理测试人员反馈的测试问题，并以书面形式反馈主要问题及解决办法，直至系统运行稳定。
6、汇总并提交所有相关文档，提交公司备案。
1.5.3.3 交付件
? 系统源代码； ? 《单元测试报告》
1.5.3.4 完成标准
系统编码结束。
14 / 52
1.5.4 软件测试
1.5.4.1 概述
软件测试包括单元测试、集成测试、系统测试、运行与验收测试，其中单元测试在系统实现阶段实现，运行与验收测试在实施与运行阶段实现。测试的内容有接口与路径测试、功能测试、健壮性测试、性能测试、用户界面测试、压力测试、可靠性测试等。
制定系统整体测试方案，将报指定的有资质认证的软件测试中心进行检测。
1.5.4.2 软件测试过程
软件测试过程如下图：
第一步：制定测试计划。 第二步：设计测试用例。 第三步：执行测试。 第四步：撰写测试报告。 第五步：消除软件缺陷。
1.5.4.3 交付件
? 《软件测试计划》
? 《软件测试报告》
15 / 52
1.5.7.3 交付件
系统试运行与维护的交付件有《系统试运行报告》。
1.6 项目进度管理
项目的进度直接关系着整个项目的成本，特别是像本项目这样长周期的系统工程项目，有效的项目进度的控制方法必不可少。
项目进度管理从以下几个步骤有序进行：活动定义、活动排序、活动资源估算、活动持续时间估算、制订进度表以及进度控制。
XX公司采用世界知名的项目管理软件PMS系统制作WBS工作分解结构，具体包括：活动定义、活动排序、活动资源估算、活动持续时间估算、制订进度表，如下图所示：
WBS工作分解
上图中每个里程碑填写完成后，项目经理必须提交审批，一经审批后项目经理不可做任何修改。通过WBS结构分解，将每项任务拆分为若干个基本的活动，同时结合里程碑和关键路径分析，精确的控制整个项目的时间进度。
根据项目成立初期做的项目进度计划，项目经理每月需提交月状态报告说明该月项目的进度情况，同时项目经理指派人员进行本项目的进度对照，出具项目进度跟踪表，根据此结果对项目进行预警或采取相应的改进措施。项目进度跟踪表如下图所示：
21 / 52
项目进度跟踪表
1.7 项目质量管理
1.7.1 目的和依据
1.7.1.1 质量保障的目的
为保证系统能够充分满足用户的质量要求，使系统实现用户要求的功能，我们站在用户立场上来掌握产品质量，我们进行有计划、有组织的系统设计开发活动，依据有关国际国内标准，在需求分析、系统开发、系统测试、人员培训等方面为项目在预定时间内完成并达到用户要求提供保证措施。
1.7.1.2 质量保障的依据
CMM和ISO9000质量体系标准，这些标准已经转化为公司标准和规范，如：《六个统一管理规定》。
XX报社集团相关标准和规范。 其他相关技术标准。
1.7.2 项目质量保障框架
项目质量保障一直是国内应用软件建设项目的难点和软件工程的关注点。北
22 / 52
京XX公司根据大量的项目经验，总结出了一套项目质量保障手段，形成了项目质量保障框架。
项目质量保障框架图
1.7.2.1 软件产品质量保障
为了确保软件质量，我们将从以下五个方面确保软件质量。 ? 需求定位保障
需求调研的完整性与准确性是软件开发质量的首要保证。如果需求调研的结果不能正确反映用户的业务，或者不能全面反映用户的业务，那么后期的软件质量无需谈起。所以，北京XX公司总结经验，提出了严格把握需求质量的管理要求。具体工作包括：
? 需求调研工作必须在用户现场进行；
? 调研过程必须有严格的工作计划，包括与用户交流的时间安排； ? 调研过程中出现的业务问题、调研时间变更问题，必须要在当日反映到项目管理层，由管理层出面解决，并由管理层备案，必要时要反映给整个项目的决策层。
? 调研人员携带录音笔的同时，必须也要有笔记，当日材料当日整理。 ? 调研过程中涉及到几个部门的复杂业务问题，必须以书面形式上报项目组长，由项目组长协调、落实解决。一时无法解决的问题，要作为重大业务问题，反映到XX报社集团党组办公会加以协调。
23 / 52
? 调研人员调研表格格式统一印制，但是调研前的调研准备情况，以及调研内容必须充实，项目质量组会对调研人员进行不定期抽查。
? 调研人员编写的《系统需求规格说明书》，必须经过北京XX公司组织的企业内部专家评审，通过后才能提交用户确认。
? 《系统需求规格说明书》必须经过确认，然后才能进入系统设计阶段。 ? 软件编码质量保障
北京XX公司根据多年的软件开发经验，总结、开发了ResouceOne软件组建架构，指在完成组建化开发体系。为此，在软件编码的规范上做了详尽的要求，具体体现在：
1) 编码风格上的要求，如类、变量、方法的命名规则。 2) 类定义的规范。 3) 编码注释规范。 4) 接口定义规范。 5) 组件定义规范
ResouceOne 软件组建架构拥有了自己的开发环境与编译环境，以确保规范的落实，提供自己的组件容器，以及组件管理与部署工具，以确保组件的可应用性。
? 软件测试质量保障
准确的说明，测试本身就是软件质量保障的重要手段。这包括我们通常所说的白盒测试与黑盒测试。我们组织专门的测试组来确保软件质量。
白盒测试主要是读码测试。我们采用交叉读码，小组讲码的方式进行。根据我们的经验，读码与讲码不仅可以发现软件编码问题，更可以实现细节沟通，优化编码结构，提升软件质量。组织读码与讲码，是公司尽一年来开发软环境建设的重要内容。
黑盒测试的测试方法：是由一些非编码人员根据《系统需求规格说明书》的要求对打包好的软件进行测试环境部署、模仿使用，以发现软件中的问题。黑盒测试包括安装测试、功能测试、组装测试、压力测试、集成环境测试五种。在该
24 / 52
项目中，我们组织了专门的测试组来完成黑盒测试。另外，用户验收过程也是一个测试过程，是一个抽测过程。我们会为用户起草验收测试方案。
再有，为了确保测试本身质量得以加强，我们在测试过程中采取了以下手段来加强测试效果，确保测试质量。
1) 采用压力测试工具，发现系统得性能承受能力； 2) 采用测试软件管理整个测试环节；
3) 编写测试案例，规范测试行为，提高测试效率； 4) 编写测试大纲，加强测试组与开发组的沟通；
5) 平台测试，平台是公司已有产品，对平台的改动由独立的测试小组完成 我们的测试方案与测试用例对XX报社集团完全公开，并且需要经过XX报社集团或其委托人审批。测试中系统如有任何部分发生故障，则测试重新开始，整个系统需整体通过测试后才标志测试工作完成，最后提交测试报告。 ? 软件部署质量保障
软件部署过程包括了系统环境搭建、应用软件安装、数据库搭建、初始数据建设、系统调优和全市联调六个环节。软件部署质量保障关键在于软件部署方案的设计与落实。为此，要有专门的文字材料，要经过总工程师的审阅与用户的认可。
软件部署方案将包括环境要求、建设步骤、参数设置、初始数据内容、以及准确的联调时间，以及联调内容。 ? 软件应用质量保障
软件应用的效果也是这次项目建设成败一个很关键的工作。具体体现在下面几个方面。
软件应用治疗保障方法
应用效果控制 培训质量 用户配合程度 系统易用性 控制方法 培训材料的准备、培训人员对培训内容的理解与掌握，培训口才，培训态度和培训时间 组织专门的交流会、项目启用动员会，现场技术支持人员的讲解，考核机制 人性化的操作、图形化的界面、非变成化的定制、“拖曳”式的流程定义、手写笔、电子盖章等。 25 / 52
1.7.2.2 技术保障
技术保障包括技术人员数量保障、技术人员素质保障和技术人员培训与考试，因此，根据我们多年相关经验，提出了“六统一”思想。 ? “六统一”介绍
以下引用自北京XX公司“六统一管理规定”：
为了规范公司软件项目的开发及提交管理，有效的利用项目资源和实现复用并且增强对项目从设计到开发以及交付各个阶段的把关，要实现六个统一：
? 统一文档管理 ? 统一build管理 ? 统一代码安全管理 ? 统一设计review ? 统一代码review ? 统一软件出版管理
其中，统一的文档管理和代码安全管理，主要是通过统一的版本控制工具管理文档和代码的版本和内容；统一的build管理和软件出版管理，是通过统一build工具、过程规范来统一的build来源和软件出版的规范，对开发结果进行统一管理控制和发布；统一review设计和代码，是通过统一的代码和设计review提高开发质量和设计水平，主要包括两方面：第一，项目经理对开发人员代码的review和review后的指导；第二，公司组织对设计review，将设计高度从项目组设计高度提升到公司设计的高度，有效复用。
针对以上的要求，基础技术资源开发与管理部之前提交了一个适用于各个团队内部的项目管理规范：《管理规范》，涵盖了整个软件过程的三条线和八个点的详细管理办法。
三条线：【文档管理】、【源代码控制】、【提交物版本控制】
八个点：【需求】、【总体设计】、【技术设计】、【开发（code）】、【开发（build）】、【测试】、【实施】、【用户验证和使用性测试】
本实施规范站在更高的层面，在各个项目组及团队之间来约束和规定各项目，保证其最新提交物能够提交到公司。不同项目组可以在权限允许的情况下直接获
26 / 52
取和参考其他项目的最新成果，并且公司可以集中优势技术资源来对各个项目的关键点进行指导和把关，避免技术方向失误及重复开发，同时也可以此为基础形成相关产品的复用。 ? 实施“六统一”
1、基础环境
开发工具：R1 Bizfoundation V5.0 开发语言：Java 2、项目定岗信息
根据“六统一管理规定”填写下表：
项目定岗信息
岗位 总设计师 项目经理 测试经理 文档管理员 代码管理员 Build管理员 姓名 3、具体任务和分工
具体任务和分工表
任务 具体内容 版本管理环境搭建和维护 建立和维护工程 源代码 权限分配 提交（含公司、客户） 代码Review 文档清单 文档 文档模版 文档Review Ant脚本维护 Build 版本标签 修改列表 提交 测试环境搭建和维护 权限分配 测试 单元测试 集成测试 27 / 52
责任人
用户提交的Bug收集 测试管理 部署 数据部署和维护 应用部署 ? 技术人员保障
北京XX公司为了提高所承接项目的质量，为了提高工作效率，在整个项目过程中对内部人员还要针对项目本身组织多次培训，确保每个项目参与人员能够高质量的完成本职工作。
? 项目背景与用户背景讲解。介绍用户的业务、组织，项目的定位、重心等内容，使整个项目团队能够宏观理解整个项目的价值和意义。从而提升团队的战斗协调性，提升团队的价值认同感。
? 需求分析讲解。根据需求调研与分析结果，给团队讲解项目的功能、流程，使各种技术人员都能够全面理解该系统，从而提高工作效率。
? 系统设计培训。根据系统设计结果，给整个团队讲解产品架构。 ? 软件编码培训。讲解编码规则、平台关联点、重点注意事项、重点函数与主要API。
? 软件部署与调试培训。讲解部署方案，系统安装过程中的注意事项。 ? 技术支持技巧培训。结合XX报社集团的实际情况，给现场运行维护人员、技术支持人员进行业务、技巧培训，做到“人对人贴身服务”。 ? 开发、测试、管理工具
系统开发工具：
1、Eclipse。是使用最普遍的，最有发展前景的J2EE开发平台软件。 2、Power Designer。是业界数据库建模的最好工具之一。 3、Rational Rose。是业界最好的面向对象的设计工具包。 系统主要工具： 1、Load Runner。是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。主要用来找到系统的性能瓶颈。
2、TestDirector。本项目采用业界流行的测试管理工具-TD辅助进行测试管理。该工具提供了以下主要功能：需求管理、缺陷管理、测试计划管理。
项目管理工具：
采用企业级项目管理方案Microsoft Enterprise Project Management Solution，进行项目进度、人力资源方面的管理，为项目的负责人提供一个全局化的视角，为各部门负责人及项目组成员提供企业级协作平台。
28 / 52
1.7.3 项目质量控制
质量管理控制主要是监督项目执行各阶段的结果，将阶段结果与事先制定的质量标准进行比较，找出其存在的差距，并分析形成这一差距的原因，质量控制同样贯穿于项目管理的全过程。
为了保证项目质量，按项目事前质量控制、事中质量控制、事后质量控制三个阶段进行划分，有关项目质量管理的具体控制措施如下：
1）项目事前质量控制：是指在项目实施前所进行的质量控制，其控制的重点是做好项目的准备工作。主要工作内容有：
? 组织准备：建立项目组织机构及质量保证机制，对项目级成员进
行有关项目质量管理方面的培训，使其提高其质量意识和素质，并将项目质量实现岗位责任制；
?
计划制订：制定好各种计划是事前质量控制的重要手段。
项目质量控制表
软件开发阶段 软件开发活动 软件开发计划 质量保证 (QA) 计划 风险管理计划 启动 评测计划 问题解决计划 产品验收计划 。。。。。 质量保证活动 计划评审 计划评审 计划评审 计划评审 计划评审 计划评审 活动时间 在生命周期目标里程碑之前和准备期间 在生命周期目标里程碑之前和准备期间 在生命周期目标里程碑之前和准备期间 在生命周期目标里程碑之前和准备期间 在生命周期目标里程碑之前和准备期间 在生命周期目标里程碑之前和准备期间
? ?
工具准备：根据项目上有关相关工具的要求，准备各种支持工具； 阶段评审：按照项目质量保证计划对项目各阶段的成果进行评审，
2）事中质量控制：是指在项目开发和实施过程中所进行的的全面质量控制。
及时发现问题，保证各阶段成果的质量；
?
系统测试：做好系统单元测试、集成测试、性能测试，确保实施
29 / 52
过程顺利；
?
项目变更管理：明确项目变更流程，严格控制项目范围的变更；
3）事后质量控制：当项目实施完处于待交接状态时，则需做好质量验收评定与项目转
移工作。其项目事后质量控制的重点包括但不限于：
? 质量检查、验收及评定：与客户就服务期内的项目质量进行总体
的质量检查、验收与评定；
? 至客户。
此外，公司接受XX报社集团指定的监理公司对本项目进行监督和管理，接受监理的监督、协调。监理公司按照与XX报社集团签订的监理合同履行监理职责。
知识转移：针对服务期内的项目实施情况进行总结，并及时移交
1.7.4 项目质量改进
XX公司提交的XX报社集成信息门户项目保证符合招标文件内容，针对在建设过程中出现的质量瑕疵将按照与客户沟通的结果进行改进，由此发生的费用由XX公司承担。
（1）质量改进应坚持全面质量管理的PDCA循环方法。随着质量管理循环的不停进行，原有的问题解决了，新的问题又产生了，问题不断产生而又不断被解决，如此循环不止，每一次循环都把质量管理活动推向一个新的高度。
（2）坚持“三全”管理：“全过程”质量管理指的就是在产品质量形成全过程中，把可以影响工程质量的环节和因素控制起来；“全员”质量管理就是上至项目经理下至一般员工，全体人员行动起来参加质量管理；“全面质量管理”就是要对项目各方面的工作质量进行管理。这个任务不仅由质量管理部门来承担，而且项目的各部门都要参加。
（3）质量改进要运用先进的管理办法、专业技术和数理统计方法。
1.7.5 质量控制的流程
为了高效率、高质量的完成本系统，我方将按以下要点进行控制：
30 / 52
质量控制节点
项目实施阶段 需求分析 ↓ 需求分析 功能设计 ↓ 实施计划 ↓ 结构设计 ↓ 设计 数据设计 ↓ 过程设计 ↓ 程序编制 ↓ 单元测试 实现 ↓ 集成测试 ↓ 用户测试 验收与运行维护 检查、评价 ↓ 运行、维护 用户文档资料检查； 程序检查（验收测试） 用户使用情况及意见 产品量（计划量、实际量），目标值完成情况 评审量 检出的差错 出错原因、处理情况及对该阶段的影响 测试环境、测试项目设定、测试用例设计 开发目的 目标值 开发量（程序、文档） 所需资源 各阶段的产品与作业内容 开发体制 评审量 差错数 捡出差错的内容 评审方法 出错原因、处理及影响 检查项目 1.8 项目监控检查
在项目进度管理和质量管理章节中，分别详细介绍了对进度和质量的控制措施，本节
重点从管理和交付物的角度进行阐述对项目的监控检查。
1.8.1 管理监控
管理控制涉及项目活动的所有方面，控制活动以会议等方式进行。会议类型包括：
? 项目启动会议：给项目提供一个良好开端，以确保清楚地定义、公布和理解重要词汇的含义（如参照、目标、调整、计划和组织等），并达成一致。
31 / 52
? 月/周进度会议：由项目经理汇报项目当前状况，并提供一个机会让项目指导委员会解决那些项目经理无法解决的项目相关问题，以便及时解决；会议召开的频度由双方决定。
? 里程碑会议：在项目的里程碑节点，由项目经理汇报项目进度和质量状况及存在的影响进度和项目质量的重大问题，由相关负责人协调解决存在的问题。
? 交付物评审会议：项目经理和业务领域专家、技术专家等相关人员一起检查相关交付物，确认项目的技术和业务问题，并按需要采取相应的措施。
? 收尾评估会议：在每个实施阶段的收尾部分进行。
? 开发结项会议：这是开发项目组的最后一个会议，用来确认并接受新开发的系统，并正式宣布本项目的开发阶段结束。
1.8.2 交付物监控
质量和技术监控主要针对特定阶段提交的交付物，而不是针对整个阶段的产品结果。目的是为了在开发阶段尽可能早的确认并改正错误。它通常采用下面控制机制：
? 质量抽查：是指技术、质量保证及用户的相关人员对交付物进行检查，确定它已经完成并符合质量标准和相关的用户需求。
? 变更控制：一个变更是指与一个或多个交付物相关的并且事先未知的需求改变。它需要被记录并应采取适当措施加以控制以防变化扩大化。
? 软件配置管理：提供一个正式的机制用来对交付物进行标记和归档，跟踪开发状态及它们之间的关系。
? 缺陷管理：缺陷是指已被认为正式通过后，发现交付物技术上有异常问题。它需被记录及改正以保持交付产品的完整性。
1.9 项目变更管理
1.9.1 项目需求变更
需求变更管理是组织、控制和文档化需求的系统方法，也是一种建立和维护用户和开发组织对于改变系统功能的协议。需求开发的结果经验证批准就定义了开发工作的需求基线,这个基线在客户和开发人员之间就构筑了一个需求约定，
32 / 52
需求管理包括在项目进展过程中维持需求约定一致性和精确性的活动。现在很多商业化的需求管理工具都能很好的支持需求管理活动。这个活动需要完成下面几个任务：
1、确定变更控制过程,确定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此流程；
2、建立软件变更控制委员会(SCCB，Software Change Control Board),组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来评估和确定需求变更；
3、进行变更影响分析,评估需求变更对项目进度、资源、工作量和项目范围以及其它需求的影响；
4、跟踪变更影响的产品,当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计文档、源代码和测试用例，这些相关部分可能也需要修改；
5、建立基准和控制版本,需求文档确定一个基线，这是一致性需求在特定时刻的快照，之后的需求变更就遵循变更控制过程即可；
6、维护变更的历史记录,记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等情况；
7、跟踪每项需求的状态,这里状态包括\确定\、\已实现\、\暂缓\、\新增\、\变更\等。建立一个数据库，其中每一条记录记录一项需求；
8、衡量需求稳定性,记录基线需求的数量和每周或每月的变更(添加、修改、删除)数量。
1.9.2 项目进度变更
由于需求变更、硬件设备到货延迟、资源短缺等原因，可能超出进度安排限度，导致项目进度变更。为避免项目进度变更带来的风险，应加强监控，尽早发现问题，明确项目变更流程，严格控制项目范围的变更，避免后期的变更造成项目成本的大幅提高。
对于调研过程中出现调研时间变更问题，必须要在当日反映到项目管理层，由管理层出面解决，并由管理层备案，必要时要反映给整个项目的决策层。
33 / 52
1.10 项目风险管理
风险管理是指为了最好地达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险涉及到对问题的理解：项目中可能发生的潜在问题，以及它们如何防碍项目的成功。
风险在字典中的解释是“损失或伤害的可能性”，一般人们对风险的理解是“可能发生的问题”。风险与许多事物都有关联，例如，一个已经投入使用的存有易燃品的仓库，随时会有发生火灾的风险。一个建设中的项目也会面临许多不确定性的风险。风险就像“隐形杀手”一样，不知什么时候会出现。无论人们是否喜欢，风险是不以人的意志为转移的。但这并不意味着风险是无法避免的。比如，人们为了避免“患上重大疾病”，平时会积极参加各种健身活动，增强体质，提高防病能力。可以说，风险的存在要求人们要积极面对风险，做到有备无患，才能将风险的影响减到最小。
在许多方面，风险管理像保险的一种形式。它是为减轻潜在的不利事件对项目的影响而采取的一项活动。
1.10.1 风险管理方法
我司根据多年的项目实施经验，总结了一整套风险管理的方法，包括从哪里找风险，怎么分析风险和如何应对风险。我们的具体做法是：
首先，在思想上保持持续不断的风险意识，积极识别各种风险，但不是事无巨细处处设防。作为项目管理人员应该清楚的认识到，项目从一开始的很多东西，比如项目建议书、可行性报告或项目计划就都是在若干假设、前提、预测的基础上完成的，这些假设、前提、预测在项目实施期间有可能成立，也有可能不成立，而这其中隐藏的问题都会为项目带来风险。
其次，从宏观和项目内部两个方面找出风险的来源。首先在宏观方面，我们从项目周期、控制过程、团队安排和人员技能等方面找出潜在的问题，并采取相应的措施规避项目风险；其次在项目内部，我们以工作分解结构图（WBS）的每个阶段成果作为风险分析的对象，从风险来源——技术性风险、协调性风险（即政企之间形成的矛盾）和执行过程产生的风险，并且结合我们公司多年的经验与
34 / 52
教训找出潜在的危害，然后运用概率、分布频率、平均数众数和头脑风暴法等技术手段进行风险的分析和量化，然后制订教育培训、严格执行公司各项规章与规范等相应的措施来规避风险。
第三，不断的进行项目风险分析。随着项目的进展，已识别出的项目干系人的风险逐渐减小，但是未识别的项目干系人的风险却越来越大，而且还有其他预想不到的情况，新情况的出现都会导致新风险的产生。因此我们在项目的实施过程中不断地进行风险分析，以便使之细化。
最后，将风险管理的计划、行动、结果进行整理、汇总和分析，形成风险管理报告，为项目的实施、控制、管理、决策提供信息基础。
1.10.2 风险识别
它是管理风险的第一步，即识别整个项目过程中可能存在的风险。一般是根据项目的性质，从潜在的事件及其产生的后果和潜在的后果及其产生的原因来检查风险。收集、整理项目可能的风险并充分征求各方意见就形成项目的风险列表。
识别风险是理解某特定项目有哪些可能令人不满意的结果的过程。通过理解风险的可能来源，你就可以进一步通过检查表、流程图或访谈等手段，来识别风险。识别风险来源可以帮助识别项目上的可能风险事件与风险症状。
风险识别的常用方法是建立潜在损失一览表。 风险识别的方法：
1、问询法（头脑风暴法、面谈法和德尔菲法等）； 2、财务报表法（各种财务报表和记录）； 3、流程图法（网络图或WBS法）； 4、现场观察；
5、历史资料（索赔记录及其他风险信息）；
6、环境分析法（相关方和社会环境变化趋势，可能变更的法律法规）等。
1.10.3 风险类型
针对本项目，可能产生的风险类型包括：
1、进度延期：由于需求变更、硬件设备到货延迟、资源短缺等原因，可能
35 / 52
三个阶段进行工作内容的准备。
系统的验收贯彻项目的全过程，对于过程中的重要提交物我们将根据实际情况将进行正式和非正式的评审活动，以便于从项目过程中就确保项目质量，确保项目验收的顺利进行。
1.13.2 验收组织
项目办、专家、用户代表和承建商组成评审委员会进行验收，对评审过程进行指导，并对验收结果进行决议。
项目办负责监督系统开发工作，用户代表负责对应用系统进行试用，项目管理文档和用户使用报告都将作为业主单位对应用系统开发工作验收的重要依据。
我们通过对多个全国性大型工程项目的成功实施验收经验的总结，验收工作的特点，力图从以下三个角度阐述清楚验收的工作内容：
为了指导系统验收工作的顺利进行，验收工作可以划分为验收前、验收中、验收后三个环节，围绕这三个环节工作内容安排如下图所示：
验收环节图
上图也是指导验收工作开展的方法之一，系统验收工作的具体内容如下： 验收前：
1）确定验收方式与周期：
? 验收方式包含：召开专家验收会议；用户现场测试等。
46 / 52
? 制定每一阶段的验收周期。
2）评审参与单位及确认人：行业用户，专家组，监理。
3）准备提交物（含标准技术规范）：确定各验收阶段的提交物名称和内容。 4）准备验收标准：准备项目验收的评价指标和各阶段验收具体工作的验收要点。
验收中：
1）提交物验收（含标准技术规范）：主要是根据验收的评价指标严格评审提交物的质量。
2）应用系统建设效果验收：主要从应用系统比对合同内容功能和应用系统的部署效果两个方面考察应用系统建设效果。
3）用户使用效果：主要以《用户对系统满意度综合评价报告》和《用户对服务满意度综合评价报告》作为验收工作的参照物考察用户使用效果。
4）验收状态：通过、整改。 验收后：
1）提交物完善：根据验收小组的验收结论，对相应提交物及时完善并提交，视具体情况决定是否再次组织验收会议。
2）验收方案的调整细化：根据项目的整体建设情况，可以对验收方案做出合理的细化工作。
3）确定下一步工作计划：主要指在通过一阶段验收后，承建商必须确定下一步的实施工作内容，验收小组也必须确定下一步验收工作的计划和内容。
1.13.3 验收步骤
1.提出验收申请
根据每个阶段的验收要求，在自验通过后需要由系统承建商提出验收申请，经甲方批准后，方可启动评估。
2.启动验收评估
对于每一个验收阶段，验收前都需要进行验收准备工作，确定验收方法，验收范围，验收标准，细化验收方案等。
47 / 52
3.确定验收涉众
启动验收后，需要细化哪些组织、人员需要参与到验收工作中，需要定义验收组织中的基本角色和各自的职责。
其中，需要确定关键人员是否需要全职进行评估工作，并保证全体参与人员能够正确全面地理解评估流程。
参与评估人员一般包括：
? 评估方：1）业务骨干；2）技术骨干 ? 监理方：1）项目经理；
? 专家组：1）技术专家；2）业务专家
? 被评估方：1）业务人员；2）项目经理；3）项目架构师；4）开发人员；5）测试人员；6）管理维护人员。
4.评估、验收
由验收人员根据验收方法、验收原则和验收方案对评估范围内的项目进行评估，并对评估结果进行记录和分析。
5.做出验收结论
根据评估结果，确认本次评估是否通过，并对通过／未通过的原因进行总结，做出评估报告。验收结果分为：验收通过、整改两种。符合信息化项目建设标准、系统运行安全可靠、任务按期保质完成、经费使用合理的，视为验收合格；由于提供材料不详难以判断，或目标任务完成不足80%而又难以确定其原因等导致验收结论争议较大的，视为不通过，需要整改。
1）项目凡具有下列情况之一的，按验收不合格处理：
? 未按项目考核指标或合同要求达到所预定的主要技术指标的； ? 所提供的验收材料不齐全或不真实的；
? 项目的内容、目标或技术路线等已进行了较大调整，但未曾得到相关单位认可的；
? 实施过程中出现重大问题，尚未解决和做出说明，或项目实施过程及结果等存在纠纷尚未解决的；
? 没有对系统或设备进行试运行，或者试运行不合格； ? 违反法律、法规的其他行为。
48 / 52
2）验收结论确认和处理
由项目验收组根据验收意见和相关资料得出结论，形成书面意见，提请监理公司审查，并经甲方确认。
3）项目验收结论的处理
? 验收结论为验收合格的，承建方将全部验收材料统一装订成册并连同相应的电子文档，正式提交甲方存档。
? 验收结论为验收不合格的，要求限期整改，整改后试运行合格的，重新申请验收。
6.项目交接与持续改进
对于通过验收的项目，承建方需要将相关文档、规范以及其他内容等正式提交用户方。
1.13.4 验收内容
验收范围涵盖系统中的各项建设内容。 1.项目调研与需求管理阶段
相关提交物：《系统需求规格说明书》、《项目进度计划》 评审内容：《系统需求规格说明书》 2．系统设计阶段
相关提交物：《系统概要设计说明书》、《系统详细设计说明书》 评审内容：《系统概要设计说明书》、《系统详细设计说明书》 3．软件测试阶段
相关提交物：《系统测试报告》
验收内容：系统初验，验收系统的部署运行情况 4．试运行及终验
相关提交物：《试运行总结报告》、《系统用户手册》、《系统安装手册》、《项目总结报告》及前期各阶段的提交物
验收内容：项目终验，验收系统的整体运行情况
49 / 52
1.13.5 验收标准
1）软件文档 项目 子项目 标识指示 项目说明 用户文档具有唯一的文档标识，版本的变更要有标准的权限及审批流程 要求系统 完整性 功能说明 用户文档应明确说明该软件的运行环境 程序中用户可调用的所有功能，都应在用户使用手册中加以完整的描述 使用手册 用户文档应包含产品使用所需的信息，包括操作说明、安装手册。 正确性 一致性 表达正确性 内容一致 用户文档中所有信息应是正确的，没有歧义和错误的表达 用户文档自身或相互之间不应相互矛盾。 用户文档应有目录表或索引表。 易浏览性 目录索引 2）功能 项目 子项目 功能的充分性 适合性 功能实现的完整性 功能实现的覆盖率 预期的准确性 项目说明 所有测试的功能都应都能正确执行 程序中应包括需求规格说明中描述的所有功能 需求规格说明中描述的所有功能应都能正确实现 针对特定任务设计的测试用例应都能得到合理的预期结果。 准确性 计算的准确性 精度 程序中所有计算的结果应准确无误。 程序应能按要求的交换格式与其他软件或系统成功进行数据交换。 数据的可交换性（基互操作性 于数据格式） 数据的可交换性（基于用户成功尝试） 3）可靠性 项目 子项目 针对测试用例的失效成熟性 密度 故障密度 程序与其他软件或系统每次进行数据交换应都能成功执行。 程序应对所有用户访问系统和数据的操作进行记录。 项目说明 针对测试需求设计的测试用例的执行都不应引起软件失效。 针对测试需求设计的测试用例的执行都不应引起故障。 50 / 52
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库项目实施管理方案在线全文阅读。
相关推荐：