编号	阶段	工作项	完成时间（天）	完成内容
1	第一阶段	调研	T+2	成熟度评估、项目/应用现状、组织现状、工具现状
		解决方案	T+10	团队规划、流程规划、工具选型、规范规划
		部分试点系统	T+105	确定试点系统、完成试点系统在平台上的应用流程运行、流转。
		平台部署上线及开展试点	T+18	平台部署上线
5	第二阶段	个性化需求定制化开发	T+37	根据调研情况完成定制化需求定制开发
6		新系统推广	T+50	确认新系统，团队，制定推广方案，推广实施
7		应用系统数据迁移	T+60	数据迁移方案制定。试点系统、新系统数据迁移。
8		生产系统年推广	T+65	生产系统推广方案，生产系统执行。
9		人员培训	T+75	培训计划、培训教材、培训范围等内容规划

4.2 项目人员管理

4.2.1 人员-组织架构

针对本项目我方投入拥有丰富经验和技术技能的交付和专家团队。项目经理具备丰富的项目管理与开发经验。架构师承担过公司多个项目的架构设计，具备应用运行云平台架构设计能力。开发和测试人员多次参与同类型的项目建设，经验丰富。实施人员、技术专家都是公司具备较多类似项目经验的优秀工程师和专家能够保证本项目交付工作的人力投入。按照本项目的需求情况。

4.2.2 人员-各岗位职责分工

序号	担任角色	项目职责
1	项目经理	负责项目进度控制、需求分析等核心项目管理工作。
2	系统架构师	负责系统架构设计及工程交付方案评审等技术相关管理工作。
3	开发工程师	负责系统的模块建设，代码编写等技术类工作。
4	交付工程师	负责系统方案设计、部署、实负责施和运维
5	公司顾问	负责整体技术方案设计把关，技术问题处理

4.3 人员-管理考核机制

4.3.1.1 质量考核

a、度量指标

质量度量主要是根据度量指标来进行评价的；质量指标是指软件开发程序缺陷率（bug的数量）。

b、度量指标计算方法

（1）度量指标评分标准

根据软件开发程序的缺陷率（bug量）来确定，缺陷率越高，其评价分就越低。

序号	得分	评价	缺陷率范围
1	90～100	优	0%--5%
2	70～80	良	5%--10%
3	50～60	合格	10%--15%
4	低于50	不合格	15%--100%

（2）缺陷率来源

主要是软件经过测试组测试后，所产生的测试报告；

◆开发人员的缺陷率考核，主要依据测试报告和软件维护记录；

◆测试人员的缺陷率考核，依据软件维护记录。

（3）缺陷率单位

以程序单元为单位，相比较而得出缺陷率的值（原理：缺陷数/单元总数）。这里所指的程序单元，是WBS分解后的内容。

（4）开发人员缺陷率计算方法

根据测试报告和软件维护记录中的缺陷类别，分别统计各类别的缺陷率，然后依据度量指标的计分标准表来打分。

缺陷数计算公式为：Total = ∑(Ci*Fi*Ki)；

缺陷率计算公式为：V = Total / U；

其中

i=1,2,...n代表每个缺陷；

U代表开发人员负责的、已完成且已被测试的程序单元总数；

C代表缺陷所对应的缺陷级别的权重系数；通常权重系数以"一般"缺陷级别作为基数（权数设为1），"轻微"缺陷级别可不用计算缺陷率（权数设为0）。

序号	缺陷级别	权数	备注
1	致命	3	死机，数据丢失，主要功能组完全丧失，系统悬挂
2	严重	2	主要功能丧失，导致严重的问题
3	一般	1	次要功能丧失，不太严重，如提示信息不太准确
4	轻微	0	微小的问题，对功能几乎没有影响，产品及属性仍可使用. 如有错别字

K代表缺陷所在单元对应的权重系数，开发难度增加时程序单元相应递减为0.75,0.5…（也可用分数表示更直观），具体根据具体开发项目难易程度制定。一般开发难度的单元，确定为：

序号	模块	权数	备注
1	模块1	R1
...	...	...
N	模块n	Rn

F代表缺陷所对应的测试难易的权重系数，这里是指开发人员出现bug后，判定其发现的难易程度。根据缺陷的发现难易度，将起划分为三个级别,具体可根据开发项目难易程度另行制定。

序号	级别	权数	备注
1	难	0.5
2	一般	1
3	容易	1.5

（5）测试人员缺陷率计算方法

首先根据软件维护记录表中的缺陷统计的缺陷率，然后依据度量指标计分标准表来打分。

缺陷数计算公式为：Total = ∑(Ci*Fi);

缺陷率计算公式为：V = Total / U;

所有参数含义参见开发人员缺陷率计算方法。

4.3.1.2 进程考核

对软件开发的进展情况进行度量，主要考察时间进度。

a、考核指标

¢Budget

按照对于每个单元工作量评估的结果，规定完成的时间。

¢PTC报告

通过比较实际完成时间和计划完成时间的时间差，与任务完成周期的比率来评价各任务的及时度。

以下为PTC报告：

姓名：XXX 月份：组别：开始时间：版本记录：(VX.x；X.x)

任务	描述	第1周	…	第5周	ToT	PTC	ACT	Percent	Budget	REM
T1			..
T2
…
Tn
合计					平均：

其中

TOT: 已经花费的总天数；

PTC: 除了本月花费的天数，还要多少天可以完成；

ACT: 本月实际需要的天数；

Budget:最初预计的本月需要花费的天数；

REM: 整个任务完成的期限；

Percent:本月完成的百分比。

对于每周工作过程中，所花费的天数，通过书写的“工作日志”，可以进一步核实。工作日志每天要书写，精确到小时，每周向直接上级汇报，并存档。便于抽查、核对。

对开发人员、测试人员的过程考核数据是：项目所负责的程序单元的计划完成时间和实际需要时间。

对技术执行总监的过程考核数据是：整个项目的计划完成时间和实际完成时间。

时间差率=(本月实际需要时间-本月预计完成时间)/本月预计完成时间；即：Percent。（以天为单位）；最终的结果为N个任务的平均值。

b、评分标准

时间差率范围可根据具体项目而定。

序号	得分	时间差率范围	备注
1	90-100	15％以下
2	70-80	15％-35％
3	低于70	35％以上

4.4 进度管理

项目要制定合理的进度安排，并确保项目能够按计划进行。项目经理以及各组负责人根据项目特点、客户需求、识别的风险、可能存在的限制安排项目进度；在项目执行过程中定期对所属范围内的项目进展情况进行监控，识别与分析实际进展与计划的偏离原因，采取纠正措施进行调整，必要时进行正式的计划变更。

1、进度安排

进行合理的进度安排是进行监控的前提，考虑迭代的生命周期模型，项目采取分阶段细化项目进度的策略。在项目初始策划阶段，项目制定总进度表，内容包括各主要里程碑和各迭代点；在每主要里程碑结束，细化下一里程碑的计划；在每次迭代策划阶段，制定本次迭代的进度表，细化本次迭代内的项目活动。进度安排时可以按照以下步骤进行：

n 确定可用的资源。在编制进度表时，知道在何时以何种形式取得何种资源是必要的，这种对资源可用性的了解程度是需要不断进化的。

n 确定项目日历和资源日历。项目日历和资源日历标明了在该项目中或者对于某一资源来说哪些日期是用于工作的时间。

n 根据任务的依赖关系和估计工期列出项目的关键路径，为关键路径上的各个关键任务分配资源，为非关键路径上的其它任务分配资源。

n 进度的安排可以使用表格形式或者图形形式进行表示：

任务网络图

条形图

2、进度调整

项目依据进度表的安排执行并控制项目进度，并根据项目状态对进度进行调整。使用进度表监控项目进展，进度控制的内容有：

n 对造成进度变化的因素施加影响，以保证这种变化朝着有利的方向发展。

n 收集项目实际进度状态数据，与计划进度数据进行比较，确定项目进度是否已发生变化。

n 当在实际变化发生和正在发生时，对这种变化实施管理。

根据项目状态对进度进行调整，进度调整包括两种类型，即日常调整、定期调整和项目进度发生重大变更时的调整。

日常调整指项目各级负责人日常对进度表的更新活动，可以是每天或者每周进行，一般包括对以下内容的调整：

n 调整某个任务的工期、计划开始时间或结束时间。在调整时要注意与该任务具有依赖关系的其他任务的变化，特别是要注意关键路径的变化，检查所进行的调整是否导致项目里程碑结束日期或者项目日期发生变化。

n 根据人员负荷和进度变化调整资源的分配，为某个任务重新指定资源。

n 收集并记录进度实际数据，一般包括任务的实际开始时间、实际结束时间等。

定期调整是指项目经理在迭代内里程碑、迭代结束和阶段结束通过正式评审项目进展，根据项目完成状况对项目进度的调整。

当项目进度发生重大变更时，如需求变更引起的，需要调整项目进度表，此时需要对剩余工作进行重新估计，重新制定后续任务的进度表，包括调整迭代计划以及项目总体计划。

3、资源监控

资源是指在项目运行过程中所需要的人力资源。资源监控是指项目充分、有效地利用所涉及人员的过程，包括识别并管理这些资源以及在不同阶段需要的数量、状态等信息，确保项目的正常开展。在项目策划阶段，策划合适的资源安排到各项项目任务中，形成完整的人员配备管理计划；在项目实施过程中，通过邮件、周例会和里程碑总结等正式和不正式的手段对人员的状态进行监控。一旦出现不可避免的人员变更问题，按照规定的流程进行工作交接。

项目的资源监控有两个主要特点：

n 工作匹配原则：保证为项目配备符合项目活动能力要求的工程和管理人员；

n 动态人员结构：根据不同阶段项目对人员的不同需求考虑投入不同能力和不同数量的人员。

4、人员策划

需要识别为完成项目所涉及的所有人员角色、所需的经验技能、数量要求以及投入时间等信息，建立人员需求表。

基于以上需求，获取符合项目以上需求的技术和管理人员；获取的途径包括本事业部内部、公司内部其他事业部或社会招聘。获取人员的主要考虑人员的工作能力和熟练程度，具有类似项目的技术和管理经验背景优先，同时也要考虑个人爱好和个人特点以及时间上可能性。

根据项目进度的要求和任务的安排，为每项任务分配人力资源以及每项资源在各个时间段内（天、周、月或者其它时间间隔）完成的工时，形成完整的人员配备管理计划。

在人员配备管理计划中，以图或表的形式描述了资源分配和人员负荷等情况，如下所示：

甘特图：用于为每项任务分配资源。

甘特图

任务分配状况图：描述了每项任务的资源分配状况。

任务分配状况图

资源图表：描述了各项资源的负荷情况。

资源图表

资源使用状况图：描述各项资源在每项任务上所花费的工时。

资源使用状况图

5、人员变更

项目经理跟踪人员配备管理计划以监控项目人员的投入状况，并在每周和每里程碑上进行总结，监控的主要内容包括：

n 人员投入的数量以及投入的人员技能是否可以满足项目实施要求；

n 是否需要为项目人员提供必要的培训；

n 人员负荷是否不平衡；

n 人员是否流失或有流失的可能；

在项目周会和里程碑会议上，高级管理者、客户方和项目经理评审以上人员状况，制定合理的措施以处理人员管理中遇到的一些问题。

由于人员离职或工作变动会引起项目中人员的变更。项目经理会分析人员变更所带来的影响，尽量控制人员变动，对于不可避免的人员变动要处理好工作交接，以使工作能够全面、顺利的交接，降低工作交接对项目工作带来的风险和问题。

下图描述了人员变更主要活动的流程：

人员变更流程图

对于以上人员变更活动需要注意以下内容：

n 新负责人应尽量选择在相关领域有经验的人员（由于是中途接手，难度较大）；

n 如果选择本项目中已承担其他工作任务的人员作为新负责人，则一定要准确度量其负荷，并要明确其接手后的责任；

n 交接期限的确定应以工作能够有效交接为中心，可能的情况下部门应在工作交接结束后，才最终同意原担当离职或变动工作；

n 交接计划要与项目经理和被交接者商讨制定，计划中应包含要进行哪些交接活动、时间、内容及相关人员安排等，应该包括相关培训和自学的内容。

n 项目经理要对工作交接的结果进行检查，判断相关工作是否都已经顺利交接；如果存在问题，需要与相关人员商讨后续计划。

4.5 质量管理

4.5.1 质量保证方法论

我司将质量控制和过程改善工作放在突出位置，逐渐形成了较为完善的质量、成本和交付体系。我司承诺在本项目的开发过程中，将严格过程管理，对开发过程进行有效管理和监控，确保项目开发计划的有效性。

质量管理包括保证项目满足其需求所需要的过程，包括确定质量目标和职责并通过诸如质量计划、质量控制和质量改进等手段使其实施的全面管理职能的所有活动。

在项目策划阶段，项目经理和QA依据历史数据对项目的质量目标进行估计；在项目开发实施过程中，通过收集质量数据计算质量指标分析，以周例会或里程碑总结的频度监控项目的质量状况。为了保证质量目标的实现，采取缺陷预防、技术评审、同行评审和测试等多种手段来控制和确保质量。

4.5.1.1 质量保证原则

对于本系统主要有如下几点：

n 在每个阶段开始时，需要对准备情况进行认真审查，并向工程领导小组汇报，确认已经具备了开始当前阶段工作所必须的条件后，才可开始该阶段的具体工作；

n 实施中的每个阶段有阶段工作计划，具体工作中每周有工作周计划，所有计划需要经双方讨论确认并签字生效；

n 实施中双方都应按时、圆满完成任务，并督促对方的工作；

n 实施中每阶段结束，每周工作结束，需对原定计划进行双方参与的总结，形成总结报告，对其中未按时完成部分制定补救措施和整改计划，为下一阶段的工作做好准备；

n 实施中所产生的需求分析文档、软件总体设计、数据库设计都必须进行评审，尽早发现问题所在，及时进行修改使后续工作能够正常进行；

n 以上文件评审合格后由双方签署评审意见后生效，将作为下一步工作的规范和标准，用户需求原则上不应再发生变更；如遇特殊情况需要改变需求，届时由双方再协商解决；

n 实施过程中加强沟通，包括现场工作周报，用户周报等，通过充分的信息交流了解彼此的进展情况，保证计划按时完成。

根据以上原则，在整个开发过程中，我司将运用一系列的质量保证手段保证开发质量。运用质量工具进行需求分析及软件设计，使软件易于理解、易于维护、易于测试。确保系统的正确性、完整性、实用性和高效性。

4.5.1.2 质量保证目标

我司承诺在本项目过程中，严格遵守国家、地方及招标文件中对要求遵循的各项标准，达到各项验收标准，实现保证合格，合格率100%，优良率95%以上。具体如下：

n 确保软件系统的质量，能够通过专业软件测试部门的系统性测试，并达到验收标准、符合相关规范要求；

n 确保软件质量满足系统要求，能够正常运行；

n 确保集成工程能够满足各项指标要求，布线合理，易于维护；

n 确保系统数据能够顺利采集，满足验收要求，满足各项标准；

n 确保整个系统满足招标文件提出的各项标准及规范要求；

1) 确保项目保质、保量交付，并满足用户的单位的各项需求，稳定运行。

本项目的建设包括多个阶段。在每一个阶段内，用户和我司分别承担着不同的角色和任务步骤，如何保证整个工程项目能够按时、保质、保量完成是这其中最重要的问题，为此我司将全面引入CMMI3和ISO9001质量管理体系。

4.5.1.3 质量保证方案

4.5.1.3.1 质量保证组织架构

质量保证组织架构包括项目经理、质量经理、软件测试组、软件架构设计师、设计师、实施经理、售后服务经理、以及作为公司职能部门的项目管理部。

质量保证应由项目经理全面负责，并配有专职的质量保证经理，工作职责为包括质量保证计划的制订、实施、监控等，并对质量保证过程中出现例外的仲裁。

软件测试组负责软件产品的测试流程，包括测试文档、测试工作、并监督发现问题的修改。

软件架构设计师保证系统总体架构的质量，并监督总体架构的具体实施。设计师负责各子模块的设计工作，落实软件总体架构，并负责监督设计工作的开发实现。

实施经理负责保证实施过程的质量。

售后服务经理负责保证售后服务过程的质量。

项目管理部指导项目质量保证过程，对项目质量计划的执行实施监控职责。

4.5.1.3.2 质量保证执行

质量保证经理会依据公司的项目工程过程裁剪工作表来确定计划中质量保证活动所参考的过程、规程、标准、方法、指南、模板、表格等等。

按照质量保证计划中确定的评审和审计方式来执行计划好的质量保证活动，在活动执行过程中，质量保证经理详细记载评审、审计活动情况、和发现的不符合问题等等。

在项目开发过程中，质量保证经理对负责向开发人员提供质量保证方面的咨询支持。

4.5.1.3.3 质量过程监控

在项目实施过程中，项目经理收集评审和测试过程的缺陷数据，在每周例会、里程碑总结、迭代结束、阶段结束以及项目结束时监控和评审项目的质量状况。方法如下：

n 同行评审或技术评审结束后，被评审工件的生产者将发现的缺陷数据记录在评审记录中；

n 开发人员或测试人员在完成相应的测试工作后，将缺陷数据记录在缺陷列表中；

n 模块负责人收集这些缺陷数据提交给项目经理供其进行项目级质量分析；

n 每周项目经理分析项目的质量状况，包括需求评审、设计评审、测试用例评审和测试结果。确定数量比例较大的缺陷类型，分析缺陷产生的原因，分析当前的对应措施以及今后的预防措施，并对缺陷进行横向展开；

n 在各里程碑点、迭代结束、阶段和项目结束时，项目经理总结项目质量情况，比较和预测四级质量目标的实现情况。对于目标没有或将不能实现的状况，项目经理要调整质量控制对策，分析原因启动应急措施进行处理，一般包括重新设定目标、再评审、再测试或者返工。

4.5.1.3.4 质量控制措施

为了保证质量目标的实现，需要从缺陷预防、技术评审、同行评审和测试几个方面加以考虑，以下分别详细进行介绍：

一、缺陷预防

缺陷预防的目的是鉴别缺陷的原因并防止类似的缺陷再次出现，包括人工检查、自动化工具检查等，有效地实施缺陷预防包括以下几个活动：

1) 在项目策划阶段，项目经理在组织统一的缺陷预防措施基础上，根据本项目的具体情况进行调整，建立项目特定的缺陷预防措施，这些措施覆盖了项目开发的各个阶段；

2) 另外，在项目策划阶段，项目经理需要确定本项目原因分析会议的召开时机和参与人员。原因分析会议召开的原则是稳定的软件过程不能满足已确定的质量和过程性能目标；项目执行过程中，缺陷数目超出预定目标或发现大量问题；项目一个阶段完成或软件软件系统交给客户之后；

3) 在项目各项活动开展时，召开项目阶段启动会议，讲解本阶段的缺陷预防措施，确保项目成员正确理解并重视所执行活动的缺陷预防措施；

4) 按计划召开原因分析会议，分析本项目产生的缺陷数据，通过帕雷托方法和鱼骨图方法识别占有较大数量的缺陷类型的缺陷产生的根本原因，制定相应的行动计划，一方面完善软件开发过程，另一方面完善项目的缺陷预防措施。

二、技术评审

本项目项目建立以技术骨干为核心的技术评审组，检查软件工件是否满足规格要求和相关的标准，是否能够完成预定的目标，是否可以作为下一阶段工作的输入。

技术评审组的人员包括但不限于以下人员：客户、项目经理、项目软件经理以及项目在需求分析和设计方面的技术骨干。

技术评审主要关注以下几个方面的问题：

n 软件系统能够完成预定的功能；

n 软件系统能够覆盖所有的需求；

n 软件系统符合相关的标准和规范；

n 软件工件是一致并且完整的等。

技术评审的对象主要包括需求分析报告、架构设计报告以及详细设计报告。以上软件系统只有通过技术评审才可以作为下阶段活动的输入文档。

本项目的技术评审要求召集所有技术评审组的人员开会的形式进行，会议可以现场、电话或者视频会议的形式。

三、同行评审

同行评审的目的是为了确保及早地和高效率地从软件工件中消除缺陷，提高软件系统的质量，降低软件开发的成本。技术评审和同行评审关注的都是技术上的问题，但技术评审的对象是一个完整的软件工件，从完备性和整体上检查软件工件。同行评审的对象一般是软件工件的部分，检查的目标是软件工件中存在的缺陷。不能通过同行评审来实现技术评审的功能，但充分的同行评审能够加快技术评审的进度，节省技术评审的时间。

为了确保评审的有效进行，本项目对同行评审的基本要求如下：

n 指定专门的同行评审负责人，负责策划和协调同行评审活动；

n 针对不同的软件工件设定合适的评审覆盖度和策略，如对重要模块的有关需求、设计文档以及源代码要达到100%的评审覆盖度。

n 严格控制每次评审有足够的参与者，一般包括但不限于：客户、项目软件经理、上游活动责任人、下游活动责任人、有经验的同行。参与人员的数量保证在3-7人的规模；

n 为提高评审效率，在同行评审会议上要集中精力讨论发现缺陷，而不是如何解决这个缺陷。

n 为保证评审的效果，可采取在评审会议上阅读文档资料的方式，提高软件工件的可理解性。

n 对于规模较大的工件采取分阶段或多次的评审方式，确保评审的效果。

n 借助电话、视频等工具采用分布式评审方式解决异地开发的评审问题。

四、测试

测试的目的是为了进行适当的质量评价，尽可能检出错误，并且对于未检出错误的部分，要保证一定的质量。从质量保证的角度，项目的测试活动与各项开发活动一一进行对应，下表描述了这一关系：

图测试活动与各项开发活动对应图

为确保系统测试活动的有效进行，本项目开发项目组的针对测试活动的基本要求如下：

n 建立独立的测试组，由系统测试经理负责策划和实施系统测试；

n 建立单独的测试计划，包括策划项目的测试方法、测试类型、测试手段和测试内容、测试环境和测试工具、测试活动的进度和人员以及测试过程中的风险。

n 建立不同测试类型的测试规范，针对不同测试类型选择合适的自动测试工具；

n 建立明确的测试标准，包括测试入口标准、执行标准以及完成和成功的标准。

n 不符合问题跟踪与解决

质量保证经理依据公司的项目工程过程裁剪工作表来确定计划中质量保证活动所参考的过程、规程、标准、方法、指南、模板、表格等等。按照质量保证计划中确定的评审和审计方式来执行计划好的质量保证活动。在活动执行过程中，质量保证经理详细记载评审、审计活动情况、和发现的不符合问题等等。在项目开发过程中，质量保证经理对负责向开发人员提供质量保证方面的咨询支持。

项目质量保证经理将评审或检查出的不符合问题报告给相关开发人员，一起协商问题解决措施，并将记录协商结果和措施。

与同开发人员一起协商之后也无法获得解决的问题将被提交给活动的上一级负责人，如果问题仍无法解决，以此类推，直到将问题提交给项目组、培训组、SEPG的负责人。

重大问题将会同客户和QAG专家一起协商，确定问题解决措施。质量保证经理将跟踪不符合问题的解决情况，直至问题解决。

4.5.2 质量保证措施

4.5.2.1 成立专门的QA组

项目设立专门的QA组，归属于领导小组，包括QA专员，项目经理等管理角色，整体负责项目质量。

QA组是独立于项目之外的过程管理人员，负责评审项目过程、审计系统工件、工具和设备，为项目过程状态提供可视性，向高层经理及项目经理提供QA报告。QA的工作不受项目经理的领导，具有独立的向高层经理汇报的途径。

QA组同时负责对分包方（如果有的话）相关过程和产品进行评审和审计，评价项目综合能力，为项目降低风险。

4.5.2.2 关键里程碑跟踪和控制

项目关键里程碑计划是项目管理的基准，现代质量管理认为“计划胜于检验”，“过程决定质量”，对于项目执行来讲同样是这样。计划是项目执行的指导，计划是控制的基准，计划是项目各方沟通的平台。计划制定的过程强调渐进明细和分解。

通常应用软件开发过程中项目计划容易出现的问题

n 项目计划凌乱、无序，也就是说不能从项目计划中看到项目执行全貌。对项目执行指导意义不大。

n 项目计划只是在项目开始时进行制定，在执行过程中不对计划进行及时管理，导致项目计划失效，同时失去对项目执行的指导意义。

n 项目计划不完整，只是在当前所关注的环节存在计划，导致项目执行工作不能整体上全面协调的推进。

本项目计划跟踪和控制建议：

1) 项目计划层次划分

项目计划可分为：项目里程碑计划、子项目计划、周项目计划3个层次。充分体现项目管理中渐进明细和分解的原则。

项目里程碑计划作为项目各参与方均认可的项目阶段目标指导性文件，项目各参与方均需对其负责。

对里程碑计划进行渐进明细形成子项目计划，子项目计划要说明里程碑计划中阶段目标的实现步骤和方法。

在子项目计划的指导下形成项目各参与方的周项目计划，周项目计划作为项目进度风险控制的最小单元，根据周项目计划的执行情况进行考核，并及时形成调整措施。

2) 项目计划有效性和完整性

“计划赶不上变化”，在项目执行的过程中必然会发生各种各样的情况变化，如各个层次的项目计划不能得到及时的变更控制和管理，项目计划将逐渐与项目执行情况脱节并失效。项目计划的有效性的丧失必然导致项目工作陷入无序状态，最终导致项目目标不能实现，造成项目失败。

在形成各个阶段或维度的子项目计划时，非常重要的一点是要保证项目计划的完整性。如果子项目计划存在缺失，会造成项目执行中的重大缺陷，对整体项目执行产生重大影响。

针对项目计划的有效性和完整性问题提出本项目中相关项目管理建议：

n 项目管理组承担项目计划的变更控制和管理职能，对项目计划的有效性负全面责任。

n 建立项目计划变更控制流程。在项目执行情况发生重大变更时，相关方必须向本项目管理组提出变更申请；项目管理组根据情况及时组织项目相关方审查项目变更，并进行风险分析，更新项目计划并通知项目各方。

n 项目总体计划和子项目计划制定，要进行相关评审，在评审通过后方可生效。

n 建立项目计划标识体系，包括项目计划版本标识。每次项目计划的变更均需更新标识，并说明变更原因和进行相关风险的说明。

n 项目计划的执行情况跟踪

本着及早发现问题的原则，定期的对项目计划的执行情况进行跟踪，并对跟踪结果进行公布。跟踪的频度与项目执行情况相关，可以以周、两周等频度进行。

4.5.2.3 关键里程碑评审及汇报

整个项目过程中，对于制定的质量保证计划中设定的关键里程碑，进行严格的评审机制，根据每个里程碑的特点，要求项目中不同角色的人参与评审活动，形成严格的评审会议记录和评审问题记录，发送项目相关干系者。

关键里程碑的评审应当邀请项目管理办公室参加；项目关键里程碑达成时，要按质量计划要求进行评审、形成评审记录或报告，并将相关评审记录和问题报告应当发送项目管理办公室；项目重大质量问题应当及时向项目管理办公室报告。

4.5.2.4 项目问题和缺陷跟踪机制

对于软件开发工程项目来讲，项目在执行的过程中会出现很多问题，同时在项目监控的过程中也会发现一些缺陷。这是由于软件开发项目不确定性大的自然属性所造成。

在本项目中，对于项目中的存在问题和缺陷，建立持续的跟踪机制，由项目管理组统一负责，项目管理组协调项目各方制定处理方案，并对处理方案的执行持续跟进。

4.5.2.5 服务过程质量监控

可以采取以下步骤实施全面质量控制：

一、建立标准化工作程序

项目启动时，项目技术协调组应根据项目范围、项目要求，首先组织人力编制项目程序、工作标准及相应工作手册，形成工作方法体系，实现项目工作的程序化、标准化，并对项目人员进行培训，使他们了解和遵守项目程序和要求。

二、实行阶段性成果提交与变更控制

项目具有生命周期，这就为我们划分项目阶段提供了依据。一个大项目可分成若干阶段，每个阶段有自已的任务和成果。这样一方面便于管理和控制项目进度，另一方面可以增强项目人员和用户的信心。

在每个阶段末要提交部分成果，作为下一阶段开发的基础。成果提交之后不是不能修改，而是其修改要经过一定的审批程序，并且涉及到项目计划的调整。

三、实行里程碑式的审查与版本控制

里程碑式审查就是在项目生命周期每个阶段结束之前，都正式使用结束标准对该阶段提交的成果进行严格技术审查，如果发现问题，应及时在阶段内解决。

版本控制是保证项目部顺利工作的重要手段。版本控制的含义是通过给文档和程序文件编上版本号，记录每次的修改信息，使项目部的所有成员都了解文档和程序的修改过程。

四、全面测试

要采用适当的手段，对系统调查、系统分析、系统设计、实现和文档进行全面测试。

五、用户单位加强监督

为进一步加强项目质量控制，要加强用户方对项目质量的监督。

4.5.2.6 质量数据指标及分析

主要质量指标

指标		说明
主要指标	总缺陷密度	发现的总缺陷数与软件系统有效代码行数之比
	过程内缺陷密度	软件系统提交之前发现的缺陷数与软件系统有效代码行数之比
	提交后缺陷密度	软件系统提交之后发现的缺陷数与软件系统有效代码行数之比
阶段指标	需求缺陷密度	需求评审发现的缺陷数与估计的代码行数之比
	分析设计缺陷密度	分析设计评审发现的缺陷数与估计的代码行数之比
	代码评审缺陷密度	代码评审发现的缺陷数与实际评审的代码行数之比
	测试用例密度	测试用例数与估计的代码行数之比
	测试缺陷密度	测试发现的缺陷数与实际有效代码行数之比

项目执行过程中及时分析评审和测试过程中所收集的质量和缺陷数据，及时发现项目质量问题，以采取有效的质量控制措施。由项目经理和测试经理负责定期对缺陷数据进行分析，主要的分析包括：缺陷趋势分析、未对应完的BUG数分析、帕列托分析、缺陷等级分析和缺陷分布分析等。

缺陷趋势分析：如下图所示，用于分析测试过程中缺陷发现和修正的进展状况。项目经理跟踪项目当前缺陷实际发现和消除情况，包括发现的缺陷总数、需修改的和已修改的缺陷总数，比较需修改的缺陷数与已修改的缺陷数之间的差异。如果缺陷修正和发现数量的偏离趋势逐渐变大时，说明开发活动进展比测试活动进展慢，项目应分析原因并采取相应的措施以控制这种偏离趋势。

说明: QUALITY1

帕雷托分析：如下图所示，按照从大到小的顺序描述了各类缺陷的分布情况，按照帕雷托的原则分析占项目80%缺陷数量的少数几类缺陷，分析缺陷产生的根本原因并执行相应的预防措施以提高产品质量。Pareto的原则就是将大的问题分解成小的问题并识别出最重要的部分，使我们利用有限的资源集中解决关键的因素以得到最大的收益。

缺陷分布分析：描述项目各个版本、各个模块和阶段等多个角度考察缺陷分布情况，用于分析项目状态。下图为缺陷在各模块中的分布示意图。

质量保证经理参照我司的度量与分析规程，定期对不符合问题的数据进行统计分析，并记录解决措施，统计数据和措施，形成质量保证工作报告。

质量保证经理定期向项目经理、部门领导、客户方汇报质量保证工作状况。

4.5.3 质量目标及计划

4.5.3.1 制定质量目标

考虑迭代的生命周期模型，项目制定四级质量目标，包括项目总质量目标、阶段质量目标、每次迭代的质量目标以及每次迭代内里程碑的质量目标。前两个目标需在项目初始整体策划阶段进行策划；后两个目标是在每次迭代策划阶段。在每次策划时，项目经理组织技术骨干分析项目状况对项目的质量情况进行估计。方法如下：

n 历史数据库，寻找类似项目或者功能的质量数据，包括缺陷密度和缺陷分布。

n 根据项目规模和客户要求确定项目总缺陷数、各模块的缺陷数以及缺陷分布状况。

n 根据项目各模块开发活动所处的阶段、迭代或里程碑确定各阶段、迭代或里程碑的质量目标。

n 评审以上质量估计结果是否满足客户的质量要求，如果不能，考虑调整已确定最终的目标。

为了实现所定义的质量目标，项目需要策划适当的质量改进和预防措施，并将结果记录到软件开发计划中。另外，根据组织的要求，项目需要依据历史数据设定质量控制的阀值，以将项目质量状况波动控制在合理的范围内。

4.5.3.2 制定质量计划

在计划阶段需要采取步骤确保项目是完全按用户要求提供的交付物。每一个交付物的质量标准将被明确定义，用来制订质量保障计划。在质量计划中必须考虑抽查和定稿的流程，抽查的活动必须依据技术方案严格定义并记录成文档。因而进行的质量计划活动必须同技术计划集成在一起。在质量计划过程中，质量保证经理必须以独立的身份参与项目活动，以确保产品的质量。

以下为质量管理过程中的主要行为，它是具体的质量计划制定和执行的依据，在项目实施过程中根据项目情况制定详细的计划。

质量计划主要的行为包括：

n 项目提交物的定义和进度安排

n 合约条款的回顾审查

n 提交项和检查点的回顾审查

n 系统测试

n 错误管理和跟踪

在执行质量计划的主要任务过程中，有以下各项内容。

1) 文档规范：

n 程序和编程规范

n 设计规范

2) 技术回顾审查程序：

n 文档的回顾审查过程

n 编码和检查点的回顾审查

n 系统规格书的回顾审查

n 系统设计和详细设计的回顾审查

n 源代码的回顾审查

3) 测试程序：

n 测试队伍

n 测试过程

n 编制测试计划

n 设计测试案例

n 执行测试

n 记录测试结果

n 检查测试完成情况

n 系统集成测试

n 用户接受测试

4) 缺陷管理程序：

n 缺陷跟踪系统

n 缺陷状态

n 缺陷识别

n 缺陷确认

n 缺陷紧急级别

n 缺陷分配

n 缺陷解决

n 测试和完成

n 缺陷跟踪和监控

5. 项目团队[a4]

5.1 项目管理、实施、驻场人员清单

序号	姓名	学历	工作年限	岗位及分工
1
2
3
4
5

注：项目团队人员，不限于项目管理、实施人员、售后服务人员、驻场人员等，以及提供驻场人天数。

6. 售后服务方案

6.1 售后服务标准

一、服务与技术支持保证

我司在产品维护期内提供7*24小时技术支持服务。

1.1 ★质保期自终验验收单的日期开始计算，我司提供免费质保期为( 一 )年。

1.2 在质保期内，我司出售的相同型号产品发生硬件和软件更新/升级，我司将新发布的硬件和软件更新/升级在一个月内提供，并到现场给予支持。

1.3我司在投标总价以外单独列出质保期后的年度质保费用，我司承诺客户可在过质保期后以此价格向我司购买保修服务。

1.4我司在投标总价以外单独列出质保期后的年度技术更新/升级费用，我司承诺客户以此价格向我司购买技术更新/升级服务。

二、紧急情况服务保证

我司根据如下故障级别提供相应的服务并在故障修复后提供服务报告。

(1) 故障级别

n 一级故障：

Level 1 紧急故障，指严重设备故障，系统瘫痪，系统宕机、崩溃，或关键部件损坏，主机无法工作，业务系统无法继续运行；

n 二级故障：

Level2严重故障，部分系统故障，系统性能严重下降，主机或设备可以工作，影响和限制了业务系统运行；或系统在运行中出现的故障具有潜在的系统瘫痪或业务中断的危险。

n 三级故障：

Level3一般故障，一般性技术故障，整个系统的操作性能受损或性能下降，但系统仍可保持正常运转或行方业务运作仍可以正常工作。

(2) 故障响应

n 在一级故障发生时，我司承诺在5分钟内电话响应；提供本地化服务，本地1小时内到现场。

n 在二级故障发生时，我司承诺在10分钟内电话响应；提供本地化服务，1小时内到现场。

n 在三级故障发生时，我司承诺在15分钟内电话响应；20分钟内回复，提供本地化服务，1小时内到现场。

三、例行保养维护保证

我司提供本次购买设备保修期内的每季度巡检。巡检后我司提供现场用户签字认可的服务报告。巡检内容包括：

n 检查系统软件情况；

n 检查文件系统情况；

n 检查系统性能；

n 检查备份情况；

6.2 服务内容与方式（包含现场维保、现场服务）

6.2.1 热线支持服务

我司对客户提供长期的免费7*24热线支持服务。此外，客服中心全部人员的手机7×24小时开机，并且开通呼叫转移和秘书台等服务，确保客户能够及时与技术支持人员取得联系。我们保证7×24小时实时响应客户的技术支持与服务需求。

接到客户的技术支持请求或故障报告后，客服中心将立即以电话方式详细了解其所需的服务内容，提供相应解答，并且填写详细的记录表单。

对于技术咨询，技术人员会结合实际情况及时为客户提供相应的答复。

对于系统运行故障，客服人员首先会了解与故障有关的详细情况，在技术支持人员的配合下进行系统分析，逐步排除故障。

6.2.2 远程支持服务

对于通过电话支持服务中不能解决的设备故障，在条件允许的情况下，征得客户同意后，我们以远程登录的方式进行故障诊断，目的在于尽早查找故障出现的原因，最大程度地缩短故障恢复的时间。

6.2.3 现场支持服务

对于通过热线及远程支持无法解决的故障，在经过双方商议确定需要进行现场故障排除的情况下，我们将在约定的时间内委派专业的技术支持人员到达服务现场，提供现场服务响应，尽快解决问题。对于需要更换的设备或部件，客服中心将调动备品备件资源进行更换，恢复系统运行。总之，我们承诺尽最大的努力解决系统的问题，保证在最短时间之内恢复系统正常运行或者提供应急策略。对于技术故障，我们保证故障不解决，技术人员不撤离。

6.2.4 设备维修更换

在质保期内，对于正常使用过程中出现的设备损坏，我们将会负责系统的调试或更换已损坏的零部件；如不能修复，我司将提供备用设备供买方使用，直至设备故障修复。对于由于非正常使用造成的设备损坏，我司仍然会以优惠的价格更换已损坏的零部件；如不能修复，我司将提供备用设备供买方使用，直至设备故障修复，此时将根据设备的损坏情况收取一定的费用，其中包括：所损坏的零部件的更换或维修费用，以及相应的运输费用。

我司为了保证大型项目的实施及运行，配置充足的备品、备件是十分重要的。公司承诺向客户提供长期的备品、备件支持。我司和设备生产厂商将共同组建完善的备品备件体系，保证客户获得及时、充足的备件供应。在质保期之后，我司仍然会与设备厂商一起对客户提供长期的备件供应。

6.2.5 技术共享服务

我司通过技术支持经验的积累，建立技术支持知识库对保证整个系统稳定运行至关重要。

项目的实施过程及技术支持与服务过程中，公司技术人员将在技术支持知识库中实时统计记录发生的技术问题，同时，在每季度末将安排客服中心资深技术支持人员将本项目中出现的技术问题及解决办法进行汇总分类、整理并发布。及时同步客户技术人员。帮助客户对知识库进行丰富和更新，以便客户技术人员能够了解和掌握最新的技术、产品信息。

6.2.6 定期巡检服务

为了预防系统运行中出现故障、降低故障率、延长系统使用寿命、维持系统良好的运行状况，需要对系统进行日常保养。我司将通过定期巡检服务指导和帮助客户做好系统的日常保养工作。

系统进入运行阶段后，我司将安排工程师进行现场巡检，了解、分析系统的运行状况，一方面预防故障的发生，另一方面对发生的各种问题及时做出响应和处理，并提交巡检报告以及对今后系统维护工作的建议。

我们为定期巡检设计了专用的巡检报告，每次巡检完成由客户签字确认。

6.2.7 软件升级服务

对提供的所有软硬件产品免费提供一年系统版本升级，维护服务；升级是对现有软硬件已发现问题的修正，我们预先制定可靠的版本升级方案，并通过电话指导、远程支持或现场服务的方式协助客户完成软件升级。

6.2.8 性能调优服务

为客户提供对系统性能优化服务。公司将与客户技术人员进行联系，了解当前系统运行状况，根据实际情况为客户系统性能提供优化建议，并和客户一起制定系统优化方案。我司的技术人员和客户一起根据系统优化方案对系统进行性能调优。

6.2.9 容量评估服务

随着客户业务的迅速发展，系统有扩容需求时，我司将为客户提供系统容量评估服务。我们将根据客户系统运行状况，提出系统扩容建议，并和客户一起制定系统扩容方案。

6.2.10 紧急需求服务

紧急需求服务是指在用户提出特殊要求（如功能、结构的变更）和因意外原因遇到困难时提供的紧急支援服务。特殊要求主要是指客户在使用中要求对外观、功能或者结构进行变更等；意外原因主要是指用户在地震、水灾导致的产品破坏等特殊情况下，要求进行现场保护等。一旦收到用户的上述紧急需求，我司将帮助和指导客户解决。

6.3 长期技术服务措施

6.3.1 质保期内技术服务

技术支持及售后服务内容应包括但下述内容：升级服务、定期巡检、性能调优、故障排除等。

1、技术咨询服务

提供终身的技术咨询服务，包括新软件新技术通报，软硬件技术咨询，系统改进意见，提供技术方案，项目长远规划，研究解决技术难题等。

2、维护服务

我司协助行方完成日常系统及应用的维护工作，保证系统的正常运行。

3、巡检服务

我司定期派合格工程师到行方现场对软件进行巡检，全面检查系统的软、硬件运行情况，记录系统的错误，排除故障隐患，进行系统调优工作。每次巡检，我司须分析系统运行情况，提供系统日常运行维护建议并形成巡检报告提交给行方，报告须经行方签字确认。

4、系统升级

我司配合行方分析系统运行状态，提出修正性软件安装的技术建议。我司应根据行方的需要，结合系统的实际情况，向行方提供系统升级报告，提供相关的升级软件，制定升级方案，提供升级安装服务。

5、补丁安装

我司为行方的操作系统提供相关的软硬件更新信息通知及安装服务，对系统的新发现的BUG、新的补丁和故障隐患进行及时的通知，防止BUG和未及时打补丁造成的故障。并提供以下信息：补丁说明书的功能描述和目的；补丁的测试结果；补丁装入的计划、步骤，用户需做的准备工作，可能对系统造成的影响。

6、现场待命

我司根据行方的需要，在特殊时期（如节假日、重大变更等重要时期）免费为行方提供现场技术支持保障，并按行方要求提交技术支持报告。

7、故障修复

故障修复指当行方的系统出现故障（如服务中断、数据丢失、系统不能正常工作等）时，我司为行方提供系统修复、备件更换及系统软件故障排除的服务。

在整个维护服务保修期内，我司为行方提供7×24的故障修复服务。当系统发生故障时，我司应在接到行方申请后1小时内作出实质性反应，并派出合格工程师在2小时内到达现场。

我司应以书面形式告知行方故障申请的方式、申请的流程，以及申请过程中需要行方准备的系统信息（如软件序列号等）。

当系统发生故障时，我司在6小时内修复故障，如6小时内未能修复故障，则须在此6小时内提出解决此类问题的紧急预案方案，以恢复系统的正常运行。

当系统发生故障时，我司须启动公司的多层技术资源支持，帮助客户排查问题，直到问题最终获得妥善处理。对于客户系统的重要问题，至少每天汇报一次问题解决情况，须协助行方进行问题定位，就解决问题所需要相关系统信息的收集方法，指导行方的技术人员。

我司须帮助行方进行问题根源的分析和诊断，提出解决问题的建议方案。

8、电话支持服务

在整个维护服务保修期内，我司为行方提供7×24的电话支持服务，受理故障报修，解答行方技术人员的技术咨询问题。我司以书面形式告知行方有效的支持服务联系电话，以及提供支持服务过程中需要行方准备的系统信息（如软件序列号等）。服务支持联系电话除指定一个固定电话号码外，另提供一个手机号码。如电话号码有变动，我司提前以书面形式通知行方。

电话支持服务内容包含系统的所有硬件、软件和配置问题。

9、电子邮件支持服务

在整个质量保证期内，我司为行方提供7×24的电子邮件支持服务，以书面形式告知行方有效的支持服务电子邮箱，以及提供支持服务过程中需要行方准备的信息（如软件序列号等），如电子邮箱有变动须提前书面通知行方。

电子邮件支持服务内容包含系统的所有硬件、软件和配置问题。

如果在系统运行过程中与其它系统无法共同正常稳定运行，我司积极配合其它系统的提供商，协助解决问题；若行方要求，必须提供免费的现场服务。

6.3.2 质保期外技术服务

为行方提供质量保证期结束后完整的服务维修计划，包括服务内容、响应时间、服务方式、费用核算、质量保障等，相关费用不计入本次招标报价。

6.3.3 服务质量保障方案

提供质量保证期内维修服务的质量保障措施。

如果由于维修服务失误或软件故障造成行方损失，除承担赔偿外，还要提供处理办法。

按照行方的需要，与行方进行技术交流。

6.3.4 运维服务保障方案

我公司设有专业的质量控制管理部，负责制定各项详细的考核指标，并接受行方的投诉，同时对内部各专业部门进行严格的监督考核，以保证向行方提供高质量的服务。

6.3.4.1 服务考核评估

我公司制定严格的服务考核评估体系，对运维服务质量进行考核，提高运维服务水平。

系统运行的主要统计：

n 系统可用率；

n 设备完好率；

n 网络设备的可用率、CPU利用率，内存占用率、磁盘空间占用率；

n 系统、设备发生故障的次数、类型和历时；

n 重大故障次数和历时；

n 用户申告次数和修复及时率；

n 发生安全事件的次数、类型和影响；

n 各类设备发生事故的次数和历时；

维护质量指标：

n 故障修复及时率——在规定时限内修复故障的次数与故障总次数之比；

n 重大故障、紧急故障发生次数——在统计时间内，重大故障发生的次数。

6.3.5 故障申报及处理

故障受理

客户服务呼叫中心负责统一受理行方故障申告。

故障转派

客户服务呼叫中心在受理故障申告后，及时进行故障转派：根据机房计算机信息设备、机房基础设施、前端设备故障、系统运行故障分类进行派单，由相应的维护人员接障。

故障解决

各类维护人员收到客户服务呼叫中心报障后，立即组织协调、解决故障。若维护人员如遇到重大故障和疑难问题则向客户服务部提交，客户服务部负责进行技术支撑；客户服务部如遇到重大故障和疑难问题则向总经理助理提交，总经理助理负责进行技术支撑。

故障上报

各单位遇到重大故障在积极处理的同时上报客户服务部，并由客户服务部统一处理。

故障通报

当各类维护人员发现影响业务的系统平台故障时及时通报客户服务部；客户服务呼叫中心对相关故障进行拦截。

故障分析报告

重大故障处理完毕后按相关维护管理规定向所属上级部门提交详细的分析报告。

故障维护考核

各类维护人员及时判断故障段落，指挥故障的修复，并清楚记录故障处理情况，按要求及时通知用户，在故障通报过程中，各工序间要进行横评配合度考核。

6.3.6 行方满意度调查

满意度调查是了解行方感受和预期的理想手段，行方满意度能否得以确保则是评价一切运维服务项目成功与否的标杆。

6.3.6.1 满意度调查内容

我公司将会开展多方面的满意度调查，包括故障受理、故障处理、技术支持等涉及到运维服务的多方面内容：

n 故障受理

n 报障方便性

n 受理人员的服务态度

n 故障处理

n 故障的处理速度

n 故障的处理结果

n 反馈的及时性

n 维护人员的服务态度

n 维护人员的技术能力

n 技术支持

n 联系技术人员的便捷程度

n 提供的技术支持的及时性

n 提供的技术支持的有效性

n 技术支持的广度和深度

6.3.6.2 满意度调查的关键点

成功的行方满意度调查应对若干关键点加以把握：

n 确定调查范围

n 应覆盖运维项目提供的所有支持服务

n 应覆盖设计相关服务属性

n 确定目标受众：

n 应涵盖全体客户

确定调查问卷，并注意避免产生歧义。应确保有关问题适合目标受众回答。

保证调查工作易于完成，尽可能降低问题难度和出现模糊答案的风险。将答案设计为―是‖和―否‖，或事先设定从0到5的取值范围。

努力引导客户理解完成调查问卷的好处。在调查结束后尽快公布结果，以便客户在印象消退之前了解有关情况。围绕调查结果展开充分沟通，并将调查成果转化为改进措施。提供有关改进措施的进展报告，如果客户未能通过调查活动看到任何成效，参与后续调查的积极性就会受到损失。

6.3.6.3 我公司对行方满意度调查的态度

我公司在战略高度重视行方满意度的测评与改进

行方满意度的测评与持续改进已纳入企业的运营管理体系，并持续采取有力的跟踪和改进措施。在行方满意度调查中，对于如何构建模型，如何设计问卷，如何采集数据，如何分析数据，都是有专业的团队和业务设计来实施。

企业实施行方满意度改进项目应有确定的组织和经费保证。

我公司对满意度调查明确了组织和经费保障

通过运营制度体系有效推动行方满意度的测评与持续改进。我公司希望通过有效的监控影响行方满意度的各驱动要素的变化，并对其重要性指标和表现的结果作出深入分析，从而指导在生产经营中更好地配置资源，并有效地提高经营绩效。

6.3.6.4 满意度调查的受众

n 本项目相关领导

n 本项目行方（使用用户、报障用户）

n 本项目监理单位

n 其他本项目重要干系人

6.3.6.5 满意度调查的形式

我公司主要采用的行方满意调查的手段以电话、文本问卷、服务现场表格等。行方满意度调查表格式模板举例如下：

一、热线服务顾客满意度调查表

热线服务顾客满意度调查表
热线服务
热线服务时间	（）很满意（）满意（）一般（）不太满意（）很不满意
服务热线接通	（）很满意（）满意（）一般（）不太满意（）很不满意
热线服务人员的服务态度	（）很满意（）满意（）一般（）不太满意（）很不满意
热线服务人员的责任心	（）很满意（）满意（）一般（）不太满意（）很不满意
热线服务人员的专业知识水平	（）很满意（）满意（）一般（）不太满意（）很不满意
未解决问题回复的及时率	（）很满意（）满意（）一般（）不太满意（）很不满意

二、维修服务顾客满意度调查表

热线服务顾客满意度调查表
热线服务
产品出现问题后的处理流程	（）很满意（）满意（）一般（）不太满意（）很不满意
维修品的修复质量	（）很满意（）满意（）一般（）不太满意（）很不满意
维修产品的返回速度（是否很及时）	（）很满意（）满意（）一般（）不太满意（）很不满意
更换新品的返回速度（是否很及时）	（）很满意（）满意（）一般（）不太满意（）很不满意
维修工程师的服务态度	（）很满意（）满意（）一般（）不太满意（）很不满意

6.3.7 服务记录管理

我司使用《运行服务单》作为服务记录，记录分别由服务受理人员、服务工程师以及被服务的客户三方完成，并且由客服中心服务台统一进行定期回访，每季度根据服务单统计服务信息并形成服务报告提交给采购人。

6.3.8 文明运维管理

文明运维的组织管理

1、组织和制度管理

n 运维现场成立以项目经理为第一责任人的文明运维管理组织。

n 编制文明运维的规定。

n 设专人进行运维现场文明检查、考核及奖惩管理。

2、加强文明运维的宣传和教育

n 在坚持岗位练兵基础上，并采取派出去、请进来、短期培训、上技术课、看录像、看电视等方法狠抓教育工作。

n 特别注意对新进员工的岗前教育。

n 专业管理人员要熟悉掌握文明运维的规定。

3、现场文明运维的基本要求

n 维护人员在运维现场要佩戴工作证。

n 运维现场的材料、设备、仪器和机械堆放不得侵占场内道路及安全防护等设施。

n 运维现场的用电线路、用电设施的安装和使用必须符合安装规范和安全操作规程，并按照运维组织方案进行架设，严禁任意拉线接电。运维现场必须设有保证运维安全要求的夜间照明；危险潮湿场所的照明以及手持照明灯具，必须采用符合安全要求的电压。

n 运维机械进场前必须经过安全检查，经检查合格的方能使用，禁止无证人员操作。

n 保证运维现场道路的畅通，保持场容场貌的整洁，随时清理运维垃圾。在车辆、行人通行的地方运维，将设置运维标志。

n 维护人员必须佩戴劳动保护器具。

n 运维现场的各种安全设施和劳动保护器具必须定期进行检查和维护，及时消除隐患，保证其安全有效。

n 做好运维现场安全保卫工作，采取必要的防盗措施，在现场周边设立围护设施。

4、环境保护

n 进入机房的维护人员要自觉接受机房管理人员的监督检查，并自觉遵守机房的各项规章制度，服从机房管理人员的管理。

n 不准在机房内吸烟、饮食、睡觉。

n 不准在机房堆放材料和物品。

n 进入机房的维护人员在走前必须检查机房清洁情况，如发现不干净，必须清扫后才能离开。

n 未经用户同意，不得任意抄录、复制监控系统数据，不得随意修改系统数据。

n 维护人员将严格遵守安全保卫及通信保密制度，不得在监控机房做违反安全生产的工作，不得泄露通信机密。

n 爱护监控设施，不得随意移动监控设备，不得随意输入与监控无关的软件。

n 维护人员在进行维护工作过程中必须保持衣着整洁，在日常维护工作中涉及同客户协调时一定要保持良好形象、文明用语。

n 在维护完毕后，填写修障单，记录修复情况和数据的更新，并作存档处理。

7. 项目验收服务方案

7.1 项目验收目的

为使本项目按照技术规范的要求进行，确保项目上线后达到有关要求和标准，并能正常投入运行，必须进行项目验收。

7.2 项目验收原则

为了保证本项目实施工作完全符合项目设计的要求与合同中相关条款的约定，确保系统开通后，可以顺利运行，需要在项目实施完毕，并进行了一段稳定的试运行后，进行本系统的验收工作。

本项目的验收工作，本着坚持实事求是、客观公正、科学简便、讲求实效的原则，进行全面、认真、系统地检查验收。

7.3 项目验收前提

我司完成项目试运行并通过对系统实施的自我检测后，应按照验收文件编制要求，编制《项目验收文档》，《应急计划建议书》。验收文档应满足完整性、一致性和可读性要求。

验收前提条件还包括：

1、所有功能需求按照合同要求全部建成，并满足使用要求。

2、已编制完成验收测试方案，并经过用户单位评审通过。

3、已经完成系统的开发、测试、实施工作，并经过用户单位确认。

4、已完成所有建设项目的软件测试、整体联调测试等方面的自测。

5、各种技术文档和验收资料完备，符合合同的要求和格式。

6、符合合同或合同附件规定的其他验收条件。

在项目实施完成，并符合上述验收前提条件后，由我司提出验收申请。相关的验收文档、验收规范应提前提交给用户单位评审。

8. 培训计划

培训课程名称	培训内容	培训对象	授课方式（线上/线下）	培训时长（小时）

8.1 培训计划

8.1.1 概述

人员培训作为工程实施的一个重要环节，对整个项目的实施至关重要，通过系统的培训，使得工作人员得到日常工作需要的专业技术知识和经验，从而保障整个系统的顺利运行。

项目建设最终系统将交付用户使用，项目培训是项目实施中的重要环节，通过项目培训对业主人员进行全面的技术培训，使客户人员达到能应用平台。

8.1.1.1 培训目标

针对本项目，我司设定以下项目培训的总体目标：

n 管理员培训。

l 培训对象：系统管理员。

l 培训目的：可以独立完成平台的日常维护，解决一般问题。

l 培训内容：系统体系结构、系统配置、系统管理、系统使用。

l 培训方式：集中培训和个别培训。

l 培训批次：集中培训。

n 使用人员培训

l 培训对象：系统一般使用人员。

l 培训目的：熟练掌握所涉及部分的操作。

l 培训内容：系统使用。

l 培训方式：集中培训和个别培训。

l 培训批次：针对不同使用对象分批次培训。

8.1.1.2 培训团队组织保障

为了保证项目的培训顺利执行，专门设立了培训团队组织产保障，设立领导小组、项目管理办公室、项目经理管理组织结构。

其中项目管理办公室设立项目验收委路由器会、项目监理、业务顾问、技术顾问、项目管理顾问。项目经理架构设立技术经理、培训专家顾问、资深工程师。

本项目培训XXX将给项目组提供包含专家顾问和资深工程师等各种项目建设过程中所需要的驻场咨询、培训人员。

Diagram

Description automatically generated

8.1.1.2.1 培训团队清单

XXX对本项目十分重视，项目团队人员投入包括：专家顾问1名，资深工程师2名。共计3名项目培训人员。在项目实施过程中，我司可以根据实施的实际情况，保留或更换同等级别的人员，以确保项目实施过程的顺利进行。

8.1.1.3 培训时间和地点安排

为了更好的达到培训目的，我公司将根据客户不同的使用对象，与和客户协调时间和地点，采用不同的培训方式对相关人员进行培训。

8.1.1.4 培训对象

8.1.1.4.1 普通用户

普通用户层是应用系统的直接使用者，涉及到系统的各方面功能，是对系统功能理解最深、业务最熟悉的用户群，然而普通用户层由于覆盖的面广，各部门主要使用的功能模块不尽相同，因此针对于普通用户将按照不同的角色的侧重点进行分期培训，组织类似业务部门或单独部门进行培训，以便于各部门对各自业务系统使用的把握，以达到各用户能熟练掌握系统的使用方法。

8.1.1.4.2 系统管理员

系统管理员是业主单位对系统进行管理维护的主要人员，这一用户群掌握一定的信息技术，并且针对应用系统管理员和平台维护员分别进行针对性的培训，主要侧重于系统的建设原理和规划，总体架构，常见问题的解决，系统安装配置等内容。系统的维护和管理工作需要对应用系统较熟悉，并且能处理运行过程中遇到的各类问题，因此对于软件维护人员和管理员将采用共同参与项目维护和实施的方式，从长期实践中逐渐掌握系统维护知识，提升其技术技能和对系统的认识。

8.1.2 培训课程

我司可免费提供针对本项目的管理、维护和使用的高水平培训。培训内容应涵盖协助客户对应用进行梳理，帮助客户应用上我司平台的同时指导用户学习方法论通过培训后可以在以后自主进行应用流程梳理及上我司平台。其他包括但不限于软件功能介绍、维护管理、故障诊断等要点，使客户相关技术人员达到能独立进行管理、维护、故障处理等工作，保证系统平台能够正常、安全地运行。

我方提供的培训课程和安排在培训前会和客户相关老师确认，若客户对培训课程不满意，我司承诺在不增加费用的前提下无条件的进行调整和更换。培训内容包括但不限于以下培训：

n 产品的系统原理和功能

n 产品的使用操作

n 产品的管理维护

n 产品的故障诊断和排除

n 结合产品功能对客户研发流程的梳理

n 行业案例、流程标准培训

8.1.2.1 培训大纲（专业技术培训内容）

8.1.2.1.1 系统操作技能培训

通过此培训，使得使用人员熟悉系统的日常业务操作，是保证业务顺利进行的重要保障，培训人员能够在操作文档的帮助下独立完成日常操作。

培训内容

培训对象	培训内容	培训方法	培训人员
系统使用人员	平台操作使用培训、常见问题及解决办法	操作使用讲解	资深工程师

培训地点及人数：由客户指定并提供

培训环境及资料：由XXX提供培训环境、文字资料及讲义。

8.1.2.1.2 系统部署与维护技能培训

通过此培训，使得甲方技术人员具备独立系统日常操作与运维管理的能力。

培训内容

培训对象	培训内容	培训方法	培训人员
客户开发与维护人员	系统环境与配置信息培训：操作系统、硬件设备、中间件、网络等日常操作与配置	方法讲解、实际操作和维护	资深工程师
	产品投产流程		环境部署人员
	日常运行维护、数据备份与恢复、应急操作		维护人员
	出错的处理与解决		维护人员

培训地点及人数：由客户指定并提供

培训环境及资料：由XXX提供培训环境、文字资料及讲义。

8.1.2.1.3 相关知识培训

通过此培训，使得贵方的人员掌握相关知识，具备通过本项目的参与过程掌握基于容器技术的开发、实施能力。

培训内容

培训对象	培训内容	培训方法	培训人员
贵方技术人员	的基础知识及相关开源技术（Kubernets、Docker、CICD、微服务）等等	方法讲解、参与项目过程管理	专家顾问

培训地点及人数：由客户指定并提供

培训环境及资料：由XXX提供培训环境、文字资料及讲义。

8.1.3 培训原则

在培训过程中，我司将会严格遵循以下几项原则：

n 事先应制定完备的培训计划

由单位高层领导、人事部门、具体业务部门共同制定计划、组织实施。

n 注意全面性

高度重视对人员的全面培训。

n 注意对员工的目标激励

设计阶段性的目标，加强受训人员的自信心。

n 注重实践

培训者要引导学员积极将所学知识和技能贯彻到学以致用。

n 注重反馈

密切关注受训者情况，以决定训练进展速度和训练方法。

n 设计和策划培训：确定制约条件、培训方式和选择准则、培训计划、选择培训提供者构成了它的核心内容。该过程的重点是根据需求阶段已明确的人员能力差距策划具体的培训方案，决定“补什么”。

n 提供培训：提供培训（含培训前支持、实施培训和培训后支持）。该过程的重点在于用正确的“滋补”方式提高学员的能力，使学员真正能够从培训中学到有价值的东西，也就是解决“怎么补”的问题。

n 评价培训结果：收集资料并准备评价报告，评估本阶段培训是否到达预期效果，为下一阶段的培训策划和改进提供参考。

n 培训过程的监视和改进：培训过程的确认。

9. 服务需求部分应答

针对招标文件中的服务需求部分，每一项#号条款满足或正偏离得1分，每一项普通条款满足或正偏离得0分，总分1分。

技术人员填写“服务需求偏离表”后，此处说明有几个正偏离即可。

序号	名称	软/硬件	规格型号	详细描述	品牌	制造商名称	数量（台/套）	单价（元）	合计（元）
1
2
3
4
5
6
总价：人民币大写元整

序号	服务及其伴随的货物和工程	服务说明或主要规格	数量	履约期限	履约地点	其它
1
2
3
4
5
6

序号	评分标准	投标文件章节	投标文件所在页