软件项目实施方案书模板(投标版).docx

软件工程实施方案书模板（投标版）
角色
管理人员安排

客服中心业务经理
用户培训
XXX信息技术培训经理
质量管理
XXX客服中心领导、XXX信息技术有
限公司分管领导
系统实施和维护
XXX信息技术维护支撑经
理
深切XXX客服中心技术支撑经理
1.2. 3工程组成员
1.2. 4工程分工界面
工程组成员在工程中的分工界面如上所示，XXX信息技术的工程组成员将主要负责：
1、 系统技术架构：根据技术规范和技术方案的要求进行系统技术架构设计
2、 程序开发：完成xxx相关业务需求的功能开发
3、 程序管理：针对开发的程序源码进行管理
4、 发布管理：针对发布的程序的版本进行管理
5、 平台部署：在xxx提供的服务器上安装部署平台软件，测 试组人员负责测试，开发人员负责修复bug,测试通过后通知 XXX工程经理平台上线：负责业务上线前的基础数据配置、平台相关使 用人员的培训，并在上线初期提供10个工作日的现场技术支 持
6、 平台运维：负责对平台的监控，出现性能下降等问题应及 时给出解决方案及分析报告
xxx工程经理、业务人员等工程组成员主要负责业务规划指导、 产品管理、测试、用户体验等工作，双方在业务及技术架构设计、 测试、用户体验、发布等环节仍会有较多的交叉和交互，但是工作 重点那么有所不同。按在线客服平台的硬件、软件要求提供相关资 源，并提供网络所需访问的端口、带宽、电力以及机柜空间等供平 台使用。
1.3 工程过程模型
在过程管理上，在MSF的基础上，xxx信息技术将更多 地应用敏捷开发的快速发布原那么，通过尽早的、持续的交付有价值的 软件来使客户满意，使得开发周期尽可能缩短并能满足民生业务开展 的需要。
本工程的过程模型，以微软的MSF过程模型为主线，吸收敏捷开 发的核心理念，把传统的瀑布模型和螺旋模型的概念结合起来，并利 用了两者各自的长处。工程的过程模型把瀑布模型基于里程碑的规划 的优势与螺旋模型不断增加的反复工程交付内容的长处结合了起来， 既能到达按里程碑阶段性到达规划目标，同时又能拥抱变化，使成果 更能接近用户的需求，并且能够在更短的时间内到达目标。在需求变 更的管理上，充分表达敏捷开发的拥抱变化的理念，通过不断的版本 发布和与使用者的密切沟通，使得发布的版本不断地趋向用户的需求。 但是在实际的操作中，采用以周为周期的螺旋式版本迭代，而不是简 单采用敏捷开发每天发布的原那么，使版本的推出尽量趋近用户的需求, 同时又减少对客户工作时间的占用。
1.3. 1过程模型
工程过程模型包含范围核准、设计核准、第一次使用、产品发布 等四个主要的里程碑，每个里程碑都是一个阶段的终结点。
预想和构思阶段在“范围核准”里程碑上到达了终结点。一旦一 个新的产品（在信息基础设施实现的工程中，这样的产品可能是某项 服务）吸引了大家的兴趣并得到了允许构建的批准后，工程组开始集 中起来定义产品。前景描述文档清晰地说明了产品或服务的最终目标, 并提供了明确的方向。
设计阶段在“设计核准”里程碑上到达了终结点。工程设计包含 功能规定文档、每种角色职能组的计划组合（包括的开发、测试、用 户培训、系统实施、工程经理和产品管理）和时间进度安排。功能规 定提供给工程组足够的细节情况确定需要的资源并作出承诺。在工程 设计核准里程碑上，客户和工程组在要交付的内容上及如何进行构建 达成一致。这是一个重新评估风险、建立优先级和对时间进度和资源 调配情况做最终估计的非常重要的机会。
开发阶段在“范围完成/第一次使用”里程碑上到达了终结点。 经过核准的功能规定和相关的工程计划提供了开始开发的基准线。开 发组设置了一系列内部交付的里程碑，每个内部里程碑都要经过全部 的测试/诊断/排错的过程。在这个里程碑上客户和工程组评估产品的 功能，验证产品过渡和支持计划。同样在这个里程碑上，所有新功能 的开发都已经结束，推迟开发的功能记录下来作为下一个版本功能的 参考
稳定阶段在“产品发布”里程碑上到达了终结点。测试工作是伴 随着代码开发工作进行的，在稳定阶段因为集中注意力于寻找错误和 修改错误，所以测试活动成为主要的工作。在产品发布里程碑，产品 正式转交给操作和支持组。通常情况下，工程组或者开始下一个版本 的产品开发，或者拆散加入其它的工程开发组。

此过程模型鼓励工程组将正在开发中的工程，想象成为一个产品, 将新特色的开发和旧特色的维护作为不同版本的发布。这种概念会影 响如何设定期望，以及整个工程如何设计、规划和管理。第一个版本 的发布交付了一系列核心特色。随后的版本发布逐渐增加新的特色， 直到完成了产品的全部前景和期望。不同的版本发布不一定需要前后 衔接（也就是版本1发布后，版本2才开始）。
1.3. 2敏捷开发理念
敏捷开发是一种思维方式和软件过程方法论，敏捷开发的核心理 念包括：
1）注重概念和架构设计，而轻详细设计
敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念 设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线 规划、市场趋势、客户价值、技术趋势等。架构设计，可以看成从整 体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不 同层次和组件之间关系是什么。详细设计，那么是具体的设计和做法、 API接口等。
2） SWOT分析
在敏捷开发中，更加注重客户需求。如果对产品进行SWOT分析， 就能选出付出最小工作量，但能获得最大价值的模块。
SWOT分析阶段会在概念设计和架构设计之后进行，输入是概念 设计和架构设计，输出是模块的重要度和需要的时间。这样按照性价 比可以进行排序，选出最能符合市场的模块。
3）业务和客户驱动，而非技术驱动
在产品的敏捷开发中，虽说拥抱变化，但不盲目变化。产品的改 动需要经过概念设计、架构设计以及SWOT分析后，三思而后行。敏 捷开发中也强调"在整个工程开发期间，业务人员和开发人员必须天 天都在一起工作"，确保技术人员能够开发出客户需要的产品。
4）时刻考虑版本兼容性
敏捷开发，废除了过多冗余的文档和繁杂的设计，强调拥抱变化。 但作为产品，敏捷开发不意味着盲目地去变化。
当设计变动、API接口重构、配置文件变更时，要时刻考虑产品 的架构、规划路线图，老版本的兼容性，及迁移平滑性。否那么，随着 版本的增多，必将面对着大量的维护工作。
5）轻文档，但非无文档
敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意 味着无文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于 整理思路，加快沟通和讨论。我们产品中的文档包括：概念设计文档、 架构图、当前版本要实现的功能列表，以及SWOT分析。这些文档在 每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员 和市场的反应也会有一些变更。通过我们实践证明，这对产品的思路、 沟通讨论都非常有帮助。而且这些文档，大多是几页PPT,书写和维 护工作都很小。
敏捷开发的优点，下面是其中几点：
1、市场和需求驱动，拥抱变化
在产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示会, 把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收 集反应。此外，在开发的过程中，产品的业务人员和售前时刻保持与 产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。
2、充分利用资源和时间
采用敏捷开发，迭代开发、强调沟通、缩减文档，在每个迭代初 期就可以充分地利用开发、测试人员的时间，到达效率最大化。
3、充分自动化
敏捷开发强调拥抱变化，这必然带来动乱的产品代码变更。每一 个新的功能和修改的功能，都可以影响到其他功能，造成副作用。所 以，需要自动化去支持变化，在变化的同时保证质量和开发速度，包 括编译自动化、单元测试自动化、功能测试自动化、LH测试自动化、 集成测试自动化等。
在IM客服工程中，xxx信息技术将在开发过程中充分 运用敏捷开发的理念，使得开发过程得以缩短以满足民生要求内提供 试运行版本的需要；同时，适当加快版本迭代发布的周期（前期为1 个月，中后期为1周），使得迭代产物能更加趋近用户的需求，拥抱 变化而非死板地按照前期拟定的需求一直开发到提供初验版本。力争 在最短的时间内交付包含核心功能的可运行版本。
1.3. 3版本迭代模式
在实际操作中，我们将不拘泥于MSF和敏捷开发的标准要求，而 是根据实际情况加以应用，如以下图所示:

在本次工程中，我们根据工程的实际开展情况，设置如下方式:
1、负责构思和架构设计的人员可以与开发、测试人员并行地工 作，从而使人员的使用效率提高，开发进程得以缩短。
2、动态的迭代周期，使得初期版本推出时的无效、重复的交互 得以减少，减少了对业务人员的压力，提高了工作效率。
1.4. 工程进度管理
本工程将由经验丰富的工程经理领导工程组并控制工程进度，包 括设计、实施进度及满足各种需要的进度计划的编制、检查；实施 方案的制定与实施，经常性地对计划进度与实际进度进行比拟分 析，并及时调整计划等。
1.5. 1工程进度规划
T：合同签订时间
目录
第1章工程实施方案5
1. 1概述5
1.2工程人员组织6
1.2.1 组队模型6
1.2.2 管理人员设置9
1. 2. 3工程组成员10
1. 2. 4 工程分工界面10
1.3 工程过程模型11
1.3.1 1过程模型13
1.3.2 敏捷开发理念15
1.3.3 版本迭代模式18
1.4 工程进度管理19
1.4.1 工程进度规划19
1.4.2 工程进度控制21
1.5 工程质量管理23
1.5 . 1质量管理体系23
1.5.2 质量管理措施24
1.5.3 质量控制流程25
1.5.4 工程变更管理26
1.6 工程沟通协调28
1.6 . 1沟通措施28
1.6.2 冲突因素29
1.6.3 解决冲突31
1.7 工程风险管理33
1. 7. 1风险评估34
风险应对35
1. 7. 3 风险跟踪37
风险管理组织38
1. 7. 5 小结39
1.8工程现场管理40第2章测试验收方案43
序号
1工作内容
完成时间
备注
1
QQ客户端页面 联动子系统开 发
T+2个月

2
微信客户端营
销服务子系统
开发
T+2个月

3
消息处理子系
统开发
T+2个月

4
客服子系统开
发
T+2个月

5
知识管理子系
统开发
T+2个月

6
运营管理子系
统开发
T+2个月

7
网服子系统开
T+2个月

1.4. 2工程进度控制

发

8
报表子系统开
发
T+2个月

9
外部接口子系
统开发
T+2个月

10
硬件及网络环
境到位
T+2个月
硬件要加电、相 关的网络要具 备平台要求的 条件
11
部署及联调
T+2. 5个月

12
平台培训
T+2. 75个月

13
平台上线
T+3个月

为确保上述进度的实施，双方建立定期的工程联络会制度，以及 时协调、解决各个阶段出现的有关问题，具体细节待谈判时由双方商 定；
•在实施开始前，XXX信息技术将会提供总体工程进度
计划表及分项进度计划。从设备安装、验收、验收、交付、设 备维修等都制定详细的时间表。
• 明确工程各阶段划分，设置工程分阶段完成检测点，以控制每 个环节的按时完成。
• 深圳市XXX信息技术信息网技术工程经理 负责汇总工程阶段性工作报告，同民生工程经理一起审阅。
• 撰写工程进展和状态报告计划。
具体实施如下：
工程施工进度控制是工程管理的中心环节，在整个目标控制体系 中处于协调和带动其它工作的主导地位。是保障按时完成任务，合理 安排资源供应的重要措施。
1、工程开局，编写工程开发计划，XXX信息技术将首先 安排和重点做好以下几件事：
•明确各人员职能、职责，落实与民生各子系统负责人等相 关人员、单位的联络方式，以便各方协调配合。
•抓好系统深化设计，制定合理的分期设计计划，以控制设 计、实施两不误。
2、进度计划细化及管理，细化实施计划，将规定的任务结合在 线客服平台业务需求，在集成开始前和过程中不断地细化、调整计划, 使工程进度计划更具体、切合实际和可行。做好进度记录、及工程中 的调度等工作。
1.5 工程质量管理
如前所述，本工程采用MSF和敏捷开发相结合的过程模型，在开 发过程中，需要采取一定措施对代码质量进行管理。
1.5.1 质量管理体系
建立并不断完善质量管理体系，是整个质量管理的核心内容，它 将为质量保证活动奠定一个坚实的基础。这个管理体系是由五个质量 保证系统组成的：
一、组织架构的保证体系。这个组织架构应至少包括三个要素:
1、 最高层领导在这个组织架构中扮演的角色；全体员工参与的方式和参与的程度；
2、 专业质量管理人员的配备以及所扮演的角色。
二、规章制度的保证体系。这个规章制度也至少包括三个要素:
1、 操作流程的规范制度；信息管理的规范制度；
2、 检验程序和变更程序的操作规程。
三、质量标准的保证体系。建立这个质量标准体系的原那么有三条:
1、 > 必须有精确量化的质量指标；必须有具体明确而不是抽象含糊的质量要求；
2、 实施操作的细那么需要有统一的术语说明。
四、资源配置的保证体系。资源配置至少包括三方面的要素：
1、 设备要素，配备必要的质量检验设备，并保证生产设备本 身的质量；
2、 原材料要素，建立质量认证体系保证原材料供应链的质量 标准；人才要素，选择、配备、培训合格的质量管理专才。
五、持续改进活动的保证。
持续改进活动的内容并无定势，但一般都包括培训、检查、评比、 问题分析、征集建议等活动。
1.5. 2质量管理措施配合上述五个质量保证体系，制订相应的质量保证措施如下：
设置质量保证组织架构
最高层领导对工程最终质量负责，他可以充分调动资源并强力推 行质量目标。
工程组每个成员对自己的产出物负有质量责任。
配备专业的测试人员对程序开发的产出物进行测试，他们对程序 最终的质量起到把关的作用。
制订完善的程序管理规章制度
工程将采用统一的版本管理服务器管理工程源程序，每个人的程 序，必须经另外一个程序员检查后才能Check in,每天晚上都有 build所有程序，如果build不能通过，程序员必须立即修改自己的 程序。每隔一段时间配合进度里程碑release 一个内部版本。这样做 的主要优点：从开始程序就是一个整体，而不是到最后才整合在一起; 互相检查才能Check in可以减少错误的发生。
设置明确的质量要求和测试过程
质量要求的准那么是客户导向的准那么，就是以客户为中心，把客户 的满意度作为质量标准的尺子。这是ISO-xxxx体系的首要原那么：鉴 于顾客是组织的存在之本，因此组织不但应该了解顾客当前的需求, 而且要了解其未来潜在之需求，不但要尽力满足顾客的需求，并争取 超越顾客的期望。
测试过程是质量控制的重要环节，每一个版本的发布，都必须经 过测试人员的测试，提交测试报告通过审核后才能发布。
配置充足的人力资源确保代码质量
持续的版本迭代使质量不断改进
螺旋式的过程模型使得每一个版本的推出都能够吸收和改进前 一版本存在的缺陷，从而使程序的质量得到不断的改进。
1.5. 3质量控制流程
质量控制流程采用PDCA流程法。PDCA是四个英文词的缩写，分 别代表质量控制过程中的四个环节：
> Plan是计划，制定质量管理的目标、要求、流程、制度等；
> Do是执行，实施质量管理计划，给予组织、标准、规章、资源等方面的保障；
> Check是检验，对照计划检查实施结果，发现缺陷及偏差并寻 找原因Action是处理，对缺陷和偏差进行规范化处理，对无法进行 规范化处理的，需要对流程及计划进行调整。然后调整措施又 将被纳入下一轮新的计划，形成一个循环往复的闭路流程。
质量控制的PDCA流程贯穿了质量管理中四个最重要的概念：预 防、保证、检验、纠偏。预防和保证是为了将缺陷排除在过程之外, 检查和纠偏是为了将缺陷排除在送达客户之前，PD着眼于预防和保 证，CA着眼于检查和纠偏。
1.5. 4工程变更管理
在线客服平台工程的设计、开发、测试、推广全过程中，需要控 制来自小组内部或外部发生的，有关系统需求、功能、环境、资源、 时间等方面的改动、变化。对其影响力进行评估、权衡，与提出变更 人员、处理的有关人员协商，做出处理决定。
变更控制参与人员包括：PDM（产品经理）、PGM （程序经理）、工 程顾问组成工程变更控制小组。
变更控制小组责任：
1、让每一位相关成员了解变更带来的对自己及别人的影响;2、综合各方意见并作出结论；
3、确认受到影响的具体成员，并提出变更处理方法、时限;PDM（产品经理）或PGM （程序经理）要跟踪变更的实现,
及更新受影响的有关文档；5、对工程建设全过程中产生的变更信息进行；
6、工程在需求分析与设计阶段时，变更可以随时进行评估,但其它阶段要对接受变更与否进行权衡;
变更处理前提：
1、不能影响系统总设计目标及本次工程目标的实现。
2、变更及其处理属于工程建设小组工作范围。
3、工程领导小组要尊重控制小组的决定，外部或内部变更的提出需经过控制小组。建设小组所有成员要服从控制小组的决定，不 能未经控制小组处理，擅自实现变更改动。
变更处理流程情况
内容
1.变更提
出的书面描述
变更原因、
性质、内容、处
理建议
2.变更报
告的评估、讨论
变更版本、
理由、影响、代

情况
内容
1.变更提
出的书面描述
变更原因、
性质、内容、处
理建议
2.变更报
告的评估、讨论
变更版本、
理由、影响、代

结论时间
参与人
员
变更提出
后2小时内
变更提 出人员向变 更控制小组 提交
接收变更
报告后4小时内
变更提
出人员、变更

1.6工程沟通协调
与协调
价及好坏处

控制小组、处
理人员
3o变更处
理决定
变更处理
方法，实现程度 要求，时间安排
讨论后2小
时内
变更控
制小组
4O变更处
理跟踪
监控实现
程度，时间
处理决定 下达后，规定时 间内
变更控
制小组
5o变更归
档
变更档案 的建立、相关文 档的改动
处理决定
下达后1小时内
变更控
制小组

一个工程能否成功实施，沟通是否畅顺是关键。工程沟通是 确保工程团队的相关信息能及时、正确地产生、收集、发布、储 存和最终处理好工程信息所需的各个过程。为了确保本工程的顺 利实施，XXX信息技术将在工程实施过程中提供良好的 沟通机制。
1.6. 1沟通措施为了保证工程团队的有效沟通，我们提出了六项措施:
＞建立沟通渠道，工程组实行每周一次的例会制度，通过例会达 到工程组各方充分沟通的目的。
＞构建紧密矩阵，在空间上最大限度地缩小团队成员之间的空间 距离。在前3个月，开发人员和业务人员可以集中在民生办公, 集中在一个随时可以面对面交流的场所里办公，克服距离造成 的沟通障碍。
＞保证沟通质量，在沟通过程中鼓励信息反应，消灭晕圈效果、 虚假合意之类的无效沟通。用量化的信息代替那些“挺好、不 错、还行”之类的含糊其词。
＞排除沟通障碍，针对团队中存在的主观沟通障碍，消除不良的 消极情绪，防止背后搞小动作，鼓励有话摆在台面上说，用坦 诚对话解决问题。
＞促成意见统一，最大限度地求同存异，提取公约数。把意见的 统一作为沟通的目标，以及衡量沟通效果的质量标准。
＞筹备有效会议，会议是组织中最重要的沟通渠道，沟通的有效 性在很大程度上取决于会议的效率和效果。
通过这六项措施，我们将确保本工程在实施过程中建设方和用户 方能紧密合作、畅顺沟通，最大程度地保证工程的实施质量。
冲突因素工程实施过程中，工程团队内部产生一些冲突是正常的，也是不
2. 1验收标准43
2. 1. 1功能项测试43
2. 1.2业务流程测试43
2. 1.3容错测试43
2. 1.4平安性测试44
2. 1.5性能测试44
2. 1. 6易用性测试44
2. 1. 7适应性测试45
2. 1.8文档测试45
用户有特别要求的测试452.2测试用例编写方案及标准46
2. 2. 1 编写原那么46
2. 2.2衡量测试用例设计的质量标准47
测试用例与开发的对应关系约定47
测试用例类型约定48
2. 2.5测试阶段、类型与执行角色的关系约定49
2. 2.6测试用例清单503测试策略50
2.1.1 数据和数据库完整性测试50
2.1.2 接口测试51
2.1.3 集成测试52
2.1.4 系统测试54
2.1.5 用户界面测试55
2.1.6 3.6压力测试56
2.1.7 负载测试58
2.1.8 3.8强度测试59
2.1.9 容量测试62
2.1.10 3. 10平安性和访问控制测试63
2.1.11 11配置测试65
2.1.12 3. 12安装测试66
2. 3. 13文档测试672.4工程的交付项68
2. 4. 1 程序68
需求覆盖68
2. 4.3 文档74 可防止的。关键的问题是要知道容易产生冲突的地方在哪里，产生的 原因是什么，以便尽可能防止冲突，或有效地解决冲突。下面列出的 是最容易产生冲突的六个领域，并不涉及工程决策时干系人之间的利 益性冲突，主要指团队成员的工作性冲突。
1、进度计划：主要表现在对工时和工期估算的意见分歧。有人想 把工期拉长，减轻自己的压力，但是你的工期拖长了，别人会有意见， 这意味着别人的工期要缩短，增加别人的压力。这归根结底还是时间 资源的分配问题。
2、资源分配：供需矛盾是一对永恒的矛盾，不过管理中的供需 矛盾主要表现在各部门站在本位立场争夺资源而产生的摩擦，或者苦 乐不均产生的矛盾。
3、优先级别：既然做什么不做什么已经在立项时就决定了，那 么工程的计划实施阶段的冲突就将主要表现在先做什么，后做什么的 争议上了。既然所有的决定都在资源约束的情况下进行，那么资源的 优先分配权的问题就变成了冲突的焦点。
4、技术观点：包括对于技术方案选择、质量标准认定、操作规 范效果评价等方面的观点分歧，原因可能是方法问题也可能是利益和 责任问题。
5、行政导向：这方面的冲突涵盖面最为广泛，包括因立规、授 权、问责、奖罚、调度及管理方法而产生的各种矛盾。不按正常的指 挥链条进行沟通，例如下级的越级告状，上级的越级指挥，同级的越 权干涉，也是这方面冲突的高发领域。
6、人际关系：指因个性不合而产生的感情矛盾。工作中的矛盾 一旦升级到了个人感情的冲突，观点的分歧就演变成为对人品的偏见, 这个结就很难解开了。人际关系的矛盾往往是非理性的，带有很强的 感性色彩，这是沟通管理中最大的陷阱，被称为管理盲区，或者管理 无能区。因此，在处理工作冲突时，一定要坚持就事论事的理性原那么， 避开个人情绪化，以免将矛盾升级到感性区。
以上冲突不得到解决，将威胁工程的成功实施，因此必须在工程 开展过程中时刻关注冲突的发生并使之得到妥善解决。
1.6. 3解决冲突针对上面的冲突因素，可以有解决冲突的五种方式：
1、强制执行，在双方发生冲突时，管理级别较高的一方以权压 人，命令对方服从自己的观点和决定。从坐标系的象限位置可以看出， 这种方式有利于解决问题，但是不利于后续的人际关系。被迫服从的 一方肯定口服心不服，冲突的根源并没有被彻底解决。
2、主动解决，捅开隔在矛盾双方之间的窗户纸，通过面对面的 坦诚沟通交换意见，求同存异。这种方式既有利于解决问题，也有利 于人际关系的修复，是这五种方式的上策。管理中人们经常犯的错误 是找错了沟通对象：丙明明是对甲有意见，却对乙说，结果一旦甲得 到了风声，就会认为丙在背后挑拨他与乙的关系，从而对丙产生成见， 矛盾的种子就是这样种下的。其实这件事情很简单，丙既然对甲有意 见，直接找甲说就行了，找乙说除了发泄情绪能解决什么问题？这种 发泄情绪的做法，恰恰会陷入感情冲突的非理性区。
3、调和斡旋，当矛盾冲突陷入僵局的时候，聪明的方法是委托 一个斡旋人出面解开死结。扮演这种角色的人最好是德高望重、说话 有份量、且双方都可以接受的人物。这个调停人主要的作用其实只是 给双方台阶下。这种解决冲突的方式主要着眼于缓和人际关系，但是 未必能解决问题，双方虽然保住了面子，但是问题仍旧存在。
4、撤退回避，挂免战牌，脱离接触，把矛盾挂起来，留到以后条 件成熟了再解决。这就是我们常说的：让时间来解决问题。时间怎么 解决问题呢？从外因说，随着时间拖延，外部环境有可能朝着发生有 利于解决问题的方向变化。从内因说，时间可以腐蚀期望值，当双方 的期望值都降到了 一个合适的位置的时候，解决问题的条件或许就成 熟了。这种方法对于解决问题和人际关系的效果都未必好，因为只能 被动等待。
5、妥协折衷，就是用自己的主动让步交换对方的让步，用降低 自己诉求来交换对方降低诉求，以此来缓和冲突。这是一种不求双赢 而防止双输的做法。坚持主张需要勇气，可是妥协更需要勇气。人们 常说：胜人者易，胜已者强。意思是说，战胜自己比战胜别人更困难。 用这种方式解决问题和缓和人际关系虽然不彻底，但表现了某种主动 积极的姿态，不失为一种可取的策略。
五种方式各有优缺点，一般来说主动解决才是正解，但是在现实生活中，往往也需要其他方式加以辅助，灵活运用。
总之，XXX信息技术将在工程实施过程中，本着客观真 实、实事求是的态度，运用我们在与电信长期合作的经验，保持与民 生用户方的充分、深入的沟通，确保在工程开展过程中减少和防止冲 突的发生，即便发生冲突，也正视冲突，并通过沟通使得冲突得以化 解，从而确保工程的顺利实施。
1.7 工程风险管理
任何一个工程在设定目标，实现计划的过程中都有可能出现一些 意外的情况，或许是技术上的、或许是资源方面也可能是时间安排上 的问题。因此在工程管理方案中包含了风险管理计划。风险识别和管 理计划从进程模型的第一个阶段就开始介入，是一种预风险管理方式。 不同于一般意义上的风险管理，风险管理强调的是防止风险的发生和 减少风险的损失，而不是在风险发生之后的补救措施。经过多年在实 践中的总结，大多数的风险都是可以预见和预防的。因此利用这种预 风险管理模式作为保证工程顺利完成的基础。工程组队模型中的不同 角色在不同的实现阶段分担不同的风险识别和管理任务，保证高风险 的情况应该得到优先的解决。结合工程制定的目标，配合风险管理， 才能到达在指定时间内完成指定功能的目的。
1.8 . 1风险评估
风险管理首先需要定义风险，也就是评估风险。评估风险需要考 虑风险发生的可能性，风险的破坏力以及风险对整个工程的影响。在 正确评估了风险的基础上，需要考虑面对风险的对策，我们需要仔细 研究风险的各个方面，力求全面了解问题并确定风险的优先级，然后 考虑降低风险发生的方法，最后考虑风险发生时的对策。制定风险对 策之后那么要做风险跟踪工作，通常我们会有风险计划的更新和跟踪、 每个阶段结束后的风险总结以及随时更新的当前最主要的前几个风 险的跟踪。整个风险控制在工程的风险管理之下，能最大限度的降低 工程失败的情况。
下面是风险控制具体实施的一个模板。在风险确定阶段就需要完 成最初的风险管理文档。风险管理文档的目的是详细的记录风险的性 质，而不是简单的一个名词而已。通过风险描述，要到达全面了解风 险的目的。
最初的风险管理文档应包括：
• 风险名称
• 风险描述
• 风险状况
• 风险后果
在最初风险管理文档的基础上可以对风险进行更详细的分析，并 最终在风险管理文档中增加对风险的分析信息。通过风险分析要到达评估风险的目标，并分析补充风险的资料：
• 风险源
• 风险发生的可能性
• 风险可能造成的影响
• 风险的影响级别
• 风险对整个工程的影响
• 相关联的其它风险
在本次工程中，XXX信息技术进行了初步的风险评估, 并按照风险级别进行了排序，主要的风险列举如下：
1、时间进度风险。本次工程时间紧、任务重，能不能在民生制 定的目标时间内完成相应的开发任务，是本工程最突出的矛盾和最大 的风险。
2、程序开发风险。本次工程开发难度高，对开发人员的技能水 平、开发经验、协调沟通能力提出了很高的要求。
3、资金本钱风险。由于工程开发时间进度紧，需要在初期投入 大量的人力资源，后期维保时间又很长，需要长期投入人力维护，加 之还有第三方软件的采购，这些都给工程的资金本钱带来风险，控制 不好的话，将使工程亏损，也有可能因此影响工程实施。
1.7. 2风险应对
针对风险分析的结果，需要预先做好风险的应对计划。即如何防止这个风险的发生，当风险发生时我们需要采取的措施。为此，当完 成风险计划的时候，风险管理文档得到进一步的补充完善：
• 预防风险策略
• 预防风险策略评测
• 针对风险需要采取的行动
• 降低风险行动的最终期限
• 负责此风险的人员
• 风险时策略
• 风险时策略评测和风险时策略的触发条件
至此，风险管理文档针对可以预见的风险已经做好了预防等措施, 风险得到预先的控制和管理。
针对前述对本次工程主要风险的评估，我们已经做好了预防风险 的准备：
1、针对时间进度风险。首先是调配充足的人力资源进行工程的 实施，其次是采用分阶段的实施方式分期交付成果，在每一个阶段都 对需求内容进行风险评估，确保最需要的、最核心的功能优先得到开 发，从而加快系统的上线速度。
2、针对程序开发风险。除了调配精兵强将投入本工程的开发， 团队内部加强沟通和内部交流、培训也十分重要，通过充分的沟通统 一大家的认识，使得开发工作更为顺畅。
3、针对资金本钱风险。对投入的人力资源进行充分的考虑和计 划，例如采用重叠式的迭代开发，尽量提高人员的使用效率，一方面 要保证工程按时保质的实施，另一方面又要防止人力资源浪费导致项 目亏损。对于第三方软件那么从一开始的计划就对采购本钱进行计划和 控制，在保障民生业务需求的前提下减少第三方软件占用的资金本钱。
1.7. 3风险跟踪
风险的跟踪伴随在工程实施的整个过程中。根据风险管理文档， 可以得到当前优先级最高的前几个风险，并把这些风险作为跟踪的中 心。风险跟踪是通过风险跟踪文档来实现的。风险跟踪文档包括：
• 风险项
• 风险优先级
• 风险在跟踪状态下的时间
• 风险管理目前的进行程度
• 风险管理期中时间
• 风险管理完成时间
在风险跟踪文档产生的同时，还针对每个时间阶段（每个风险管 理期开始、期中和完成时间）形成风险状态表。风险状态表记录某一 个特定时间点上各个风险的最新情况，这些信息包括：
• 时IX
• 风险项
• 针对风险采取的措施
• 风险的负责人
• 措施前风险发生的可能性
• 措施后风险发生的可能性
• 措施前风险对工程的影响度
• 措施后风险对工程的影响度
• 当前整个工程的风险度（总计所有工程的影响度）
在工程管理体系结构中，通过上面的风险描述、风险分析、风险 跟踪来到达风险控制的目的。从整个流程上可以看到，风险管理将预 防风险的发生放在显著的位置上。其次才是在风险发生时的处理方案。
1.7. 4风险管理组织
在组队模型的六个角色设立的方式中，充分表达了工程风险管理 的概念，每个角色都从不同的角度负责方面的风险识别和风险管理任 务：
产品管理代表客户的需求，负责整个工程的整体目标和范围，保 证工程在实现的过程中符合客户的需求。防止资源方面的风险和产生 不符合客户需求的产品的风险
工程经理那么关注整个工程的进展情况，保证工程在预期的时间和 资源条件内顺利地完成所承诺的功能。防止技术方案方面和人员方面 的风险
开发集中在技术细节和人员能力方面的风险，随时评估开发过程中的细小阶段是否能按时完成，完成的局部是否符合要求等开发需要
防止在开发过程中影响完成符合功能规范产品的风险
用户教育代表最终用户的需求，负责保证最终用户使用的方便性, 是负责设计最终用户使用系统的界面和文档的小组，需要评估在用户 培训阶段要面临的问题，并提供解决的方法。防止最终用户在使用产 品时不能很快的适应新产品或者因为不能了解新产品的功能而造成 使用上的失误
测试是保证最终交付的产品是解决了所有问题的产品。测试 要承当在测试阶段时的测试方案、测试环境相关的风险。防止交付的 产品不能到达最初的设计目的
最后一个角色是推广实施，代表的是运行、支持和维护人员的需 求，负责产品在客户方的安装和设置，并保证将产品平稳的移交到产 品运行、支持和维护组手中。因此推广实施需要面临的风险是产品购 买、硬件方面和软件设置安装方面的风险。
L7. 5小结
工程的管理是围绕着资源、时间和实现功能三个方面。相应的风 险管理就面向于资源、时间和实现功能三个角度。这三者是一个三角 形的关系，任何两方面的能实现的范围决定了另一方面可以实现的范 围：例如能投入的资源（人力/物力/财力等）和开发所需要的时间决 定了应用系统可以实现功能的大致范围。因此在工程的目标/范围确
2. 5测试工具76
2. 6验收方式76
2.7成绩评定标准76第3章 技术服务方案78
3.1服务范围78
3. 2服务方式及内容78
3. 2. 1驻场+现场服务78
3. 2.2远程支持79
3.1. 故障处理流程81
3.2. 软件升级83第4章技术培训方案85
4. 1培训的对象及目标85
4.1. 培训时间及人数86
4.2. 培训方式及内容86
定阶段，就要根据三个方面能投入的力度来设置风险管理计划，当任 何一方面的投入发生变化的时候，需要修改相应的计划以防止工程的 失败。在随后的系统设计、开发、测试阶段不断更新风险管理计划, 保证在每个阶段的每种情况都有专人的负责和充足的准备，整个工程 所面临的风险都随时得到关注和解决。对于大型的工程，还可以委派 专人负责整个风险管理的管理工作，以确保风险随时得到控制。风险 计划书对整个工程组和客户都是可见的，保证它能被实时更新和及时 跟踪。
1.8 工程现场管理
按照敏捷开发的模式，同时根据民生客服中心的要求，在整个项 目开发期间，业务人员和开发人员必须在一起工作。在工程实施期间, XXX信息技术可以将派出开发团队到民生现场驻点。
现场驻点的人员包括：
1、工程经理
负责和甲方指定的产品经理进行沟通，了解并掌握用户的需求; 负责工程的总体进度控制、资源协调、质量控制、风险控制；负责对 工程组的现场工作进行管理，包括：人员管理、程序管理、制订工程 组工作计划、召集例会和各种交流培训等；2、需求分析人员
需求分析人员需要密切地和甲方的产品经理、业务人员、最终用户进行密切的沟通，深入了解并确定需求的内容和范围。
3、架构设计人员架构设计人员需要深刻地了解用户的需求，并将需求转换为可实
施、可开发的系统和程序的架构设计，架构设计人员有责任和甲方产 品负责人明确各个阶段需要完成的核心功能的范围、优先顺序，有责 任将架构设计的思路与各方沟通并得以明确。
4、UI界面设计人员
UI界面设计人员需要通过不断向用户提供原型设计，展示给用 户并根据用户的反应进行修改完善。UI设计关系到最终用户的使用 体验，是产品最终能否方便、高效、易用的关键。UI设计人员还需要 和程序开发人员密切配合，使程序开发人员深刻理解用户的操作，并 准确地实现相应的功能。
5、程序开发人员
在敏捷开发的模式里，程序开发人员除了完成程序的开发、自我 测试、程序版本和质量的控制外，很重要的工作就是需要和UI设计 人员、需求人员、乃至最终用户进行沟通，在深入了解需求的基础