2022年软件项目实施方案书模板（投标版）(完整版)

1、软件项目实施方案书模板（投标版）目录 TOC o 1-5 h z 第1章 工程实施方案51概述51.2项目人员组织61.2.1组队模型61.2.2管理人员设置91.2.3项目组成员101.2.4项目分工界面101.3项目过程模型111.3.1过程模型131.3.2敏捷开发理念151.3.3版本迭代模式181.4项目进度管理191.4.1项目进度规划191.4.2项目进度控制211.5项目质量管理231.5.1质量管理体系231.5.2质量管理措施241.5.3质量控制流程251.5.4项目变更管理261.6项目沟通协调281.6. 1沟通措施281.6.2冲突因素291.6.3解决冲突311.

2、7项目风险管理331.7.1风险评估341.7.2风险应对351.7.3风险跟踪371.7.4风险管理组织381.7.5 小结391.8项目现场管理40第2章 测试验收方案431验收标准431. 1功能项测试431.2业务流程测试432. 1.3容错测试432. 1.4安全性测试442. 1.5性能测试442. 1.6易用性测试442. 1.7适应性测试452. 1.8文档测试452. 1.9用户有特别要求的测试452.2测试用例编写方案及标准462. 2. 1编写原则462. 2.2衡量测试用例设计的质量标准472. 2.3测试用例与开发的对应关系约定472. 2.4测试用例类型约定482.

3、 2.5测试阶段、类型与执行角色的关系约定492. 2.6测试用例清单502.3测试策略502. 3.1数据和数据库完整性测试502. 3.2接口测试512. 3.3集成测试522. 3.4系统测试542. 3.5用户界面测试552. 3.6压力测试562. 3.7负载测试582. 3.8强度测试592. 3.9容量测试622. 3. 10安全性和访问控制测试632. 3. 11配置测试652. 3. 12安装测试662. 3. 13文档测试672.4项目的交付项682. 4. 1程序682.4.2需求覆盖682. 4.3文档742.5测试工具766验收方式762.7成绩评定标准76第3章技术

4、服务方案781服务范围783.2服务方式及内容782. 1驻场+现场服务782.2远程支持793.3故障处理流程813.4软件升级83第4章 技术培训方案851培训的对象及目标854.2培训时间及人数864.3培训方式及内容86第1章工程实施方案概述项目管理和实施，有着许多成熟的理论和方法，但是针对不同的 项目，不同的环境，一定需要灵活地应用才能取得良好的效果。XXX 信息网有限公司有多年的电信项目的实施管理经验，针对本项目的特 点，提出了针对性的项目实施和管理的方案。XXX信息技术有限公司提出的本项目实施方案，是在借鉴和参考 微软解决方案（Microsoft Solutions Framew

5、orks,以下简称 MSF） 以及敏捷开发的核心理念的基础上，根据以往长期与电信合作的大量 项目实例的经验总结，形成的一套适合于软件行业业务发展以及工程 建设规范的项目实施与管理方案。针对上述的实际情况,XXX信息技术有限公司在本项目的组织上, 在资源的组织和配置上，参考了 MSF的组队模型进行项目团队的组 建，从而确保用于项目的资源是充足完备的，使得项目开发的重要质 量指标得到有效的保障；在过程管理上，在MSF的基础上，更多地应 用敏捷开发的快速发布原则，通过尽早的、持续的交付有价值的软件 来使客户满意，使得开发周期尽可能缩短并能满足xxx业务开展的需 要；在需求变更的管理上，充分体现敏捷开

6、发的拥抱变化的理念，通 过不断的版本发布和与使用者的密切沟通，使得发布的版本不断地趋 向用户的需求。但是在实际的操作中，采用以周为周期的螺旋式版本 迭代，而不是简单采用敏捷开发每天发布的原则，尽量使版本推出趋 近用户的需求，同时又减少对客户工作时间的占用。项目人员组织XXX信息技术有限公司参考了 MSF的组队模型，将此次在线客服 平台项目中不同阶段的工作人员分为六个角色，通过这六个角色，项 目可以得以迅速、完善地实施。这也体现了项目开发的六个重要质量 指标。1.2.1组队模型本项目的组队模型如下图所示：组队模型由六个角色构成，这六个角色分别是：产品经理。由最终用户或懂业务的人员担任这一角色，建

7、议 由XXX方的项目负责人担任。产品经理在项目进行的全过程 中，始终代表着最终用户的利益，反映最终用户的要求。担 任这一角色的人员可以不是技术人员。但是他必须了解用户 需求，明确用户的需求以及需求的期望值。之所以强调用 户需求的期望值，是因为用户的商业化特征比较强，需求 无尽，无法界定到底如何才算需求得到了满足。而确定了 需求期望值后，用户的商业目的就非常明确，实施起来也 比较顺畅。项目经理。项目经理是一个交流与协调的角色，也是进行程 序开发管理的角色，建议由XXX信息技术有限公司富有经验 的高级项目管理人员担任。需要完成基于应用系统的业务需 求文档以及目标和范围文档，设计、管理和维护程序的功

8、能 说明。项目经理负责所有与分析、定义系统结构的管理任 务。在开发人员的配合下，项目经理必须确保功能说明在现 有的资源（时间、人力）下，技术上是可以实现的。项目经 理需要具有很强的技术能力，以便与开发人员相配合作出关 键的决策。他们需要理解项目体系结构的实质，他们常常是 项目组中最有经验的成员。项目经理必须跟踪负责整个项目 的进展。他负责制定计划，每天找出完成该计划的风险所 在，排除风险，每天交付应该完成的内容，确保计划按 质、按量实施。程序开发。开发者在开发前期就参与用户需求分析和项目 计划制定，他最清楚具体的开发过程。在开发期开始后， 他负责进行代码开发，在每一个阶段，交付每一项内容的 代

9、码。用户培训。用户培训的任务是通过应用系统的演示和培 训，尽可能地使最终用户在使用系统时能充分利用系统所 提供的功能。用户培训的第二个任务是通过编写使用文 档，使应用系统更容易被用户理解和使用，降低整个系统 技术支持的费用。作为系统的最初使用者，用户培训应参 与系统和用户界面原型的设计和构造，也参与包括程序的 安装部分的设计。伴随系统的开发过程，用户培训要根据 开发进度完成文档或电子联机文档。如果需要的话，用户 培训还要准备并交付系统的培训材料。系统测试。测试的任务是保证应用系统交付之前，能够发 现所存在的问题。测试要准备测试计划、测试规定和测试 的案例，这些文档用于有计划和目的地进行测试。测

10、试这 种角色必须独立于开发，而且测试不仅仅是代码方面的， 同时它还还应用在功能规定、系统的性能、用户界面和系 统实施等方面。部署实施。该角色规划和进行系统的安装实施，完成硬件 和软件的规划、定货、采购和安装，并且负责将开发出来 的代码在测试的或者生产的环境进行部署，使得交付的成 果可以面向用户提供使用，同时根据系统设计的部署策 略，实现系统设计所需要的容错、冗余、可靠性等要求。在本次项目的团队中，这六个角色将分别由代表客户的XXX 方人员和代表开发方的XXX信息技术有限公司成员担任，共同组 成本次项目的项目团队。1.2.2管理人员设置根据本项目的实际情况，XXX信息技术有限公司建议项目组的管理

11、人员设置如下：角色管理人员安排主僕砸XXX主管领导、XXX信息技术有限公司分管领导产品管理客服中心项目经理项目管理XXX信息技术有限公司项目经理开发组XXX信息技术有限公司高级程序 员、架构师测试组XXX信息技术有限公司专业测试经理角色管理人员安排客服中心业务经理用户培训XXX信息技术有限公司培训经理质量管理XXX客服中心领导、XXX信息技术有限公司分管领导系统实施和维护XXX信息技术有限公司维护支撑经理深圳XXX客服中心技术支撑经理1.2.3项目组成员 1.2.4项目分工界面项目组成员在项目中的分工界面如上所示，XXX信息技术有限公 司的项目组成员将主要负责：1、系统技术架构：根据技术规范和

12、技术方案的要求进行系统 技术架构设计2、程序开发：完成xxx相关业务需求的功能开发3、程序管理：针对开发的程序源码进行管理4、发布管理：针对发布的程序的版本进行管理5、平台部署：在xxx提供的服务器上安装部署平台软件，测 试组人员负责测试，开发人员负责修复bug,测试通过后通知 XXX项目经理6、平台上线：负责业务上线前的基础数据配置、平台相关使 用人员的培训，并在上线初期提供10个工作日的现场技术支 持7、平台运维：负责对平台的监控，出现性能下降等问题应及 时给出解决方案及分析报告xxx项目经理、业务人员等项目组成员主要负责业务规划指导、 产品管理、测试、用户体验等工作，双方在业务及技术架构

13、设计、 测试、用户体验、发布等环节仍会有较多的交叉和交互，但是工作 重点则有所不同。按在线客服平台的硬件、软件要求提供相关资 源，并提供网络所需访问的端口、带宽、电力以及机柜空间等供平 台使用。项目过程模型在过程管理上，在MSF的基础上，xxx信息技术有限公司将更多 地应用敏捷开发的快速发布原则，通过尽早的、持续的交付有价值的 软件来使客户满意，使得开发周期尽可能缩短并能满足民生业务开展 的需要。本项目的过程模型，以微软的MSF过程模型为主线，吸收敏捷开 发的核心理念，把传统的瀑布模型和螺旋模型的概念结合起来，并利 用了两者各自的长处。项目的过程模型把瀑布模型基于里程碑的规划 的优势与螺旋模型

14、不断增加的反复项目交付内容的长处结合了起来， 既能达到按里程碑阶段性到达规划目标，同时又能拥抱变化，使成果 更能接近用户的需求，并且能够在更短的时间内达到目标。在需求变 更的管理上，充分体现敏捷开发的拥抱变化的理念，通过不断的版本 发布和与使用者的密切沟通，使得发布的版本不断地趋向用户的需求。 但是在实际的操作中，采用以周为周期的螺旋式版本迭代，而不是简 单采用敏捷开发每天发布的原则，使版本的推出尽量趋近用户的需求, 同时又减少对客户工作时间的占用。1.3.1过程模型等四个主要的里程碑，每个里程碑都是一个阶段的终结点。预想和构思阶段在“范围核准”里程碑上到达了终结点。一旦一 个新的产品（在信息

15、基础设施实现的项目中，这样的产品可能是某项 服务）吸引了大家的兴趣并得到了允许构建的批准后，项目组开始集 中起来定义产品。前景描述文档清晰地阐明了产品或服务的最终目标, 并提供了明确的方向。设计阶段在“设计核准”里程碑上到达了终结点。项目设计包含 功能规定文档、每种角色职能组的计划组合（包括的开发、测试、用 户培训、系统实施、项目经理和产品管理）和时间进度安排。功能规 定提供给项目组足够的细节情况确定需要的资源并作出承诺。在项目 设计核准里程碑上，客户和项目组在要交付的内容上及如何进行构建 达成一致。这是一个重新评估风险、建立优先级和对时间进度和资源 调配情况做最终估计的非常重要的机会。开发阶

16、段在“范围完成/第一次使用里程碑上到达了终结点。经过核准的功能规定和相关的项目计划提供了开始开发的基准线。开 发组设置了一系列内部交付的里程碑，每个内部里程碑都要经过全部 的测试/诊断/排错的过程。在这个里程碑上客户和项目组评估产品的 功能，验证产品过渡和支持计划。同样在这个里程碑上，所有新功能 的开发都已经结束，推迟开发的功能记录下来作为下一个版本功能的 参考稳定阶段在“产品发布”里程碑上到达了终结点。测试工作是伴 随着代码开发工作进行的，在稳定阶段因为集中注意力于寻找错误和 修改错误，所以测试活动成为主要的工作。在产品发布里程碑，产品 正式转交给操作和支持组。通常情况下，项目组或者开始下一

17、个版本 的产品开发，或者拆散加入其它的项目开发组。版本1版本2版本3此过程模型鼓励项目组将正在开发中的项目，想象成为一个产品, 将新特色的开发和旧特色的维护作为不同版本的发布。这种概念会影 响如何设定期望，以及整个项目如何设计、规划和管理。第一个版本 的发布交付了一系列核心特色。随后的版本发布逐渐增加新的特色， 直到完成了产品的全部前景和期望。不同的版本发布不一定需要前后 衔接（也就是版本1发布后，版本2才开始）。1.3.2敏捷开发理念敏捷开发是一种思维方式和软件过程方法论，敏捷开发的核心理 念包括：1）注重概念和架构设计，而轻详细设计敏捷开发中，注重概念和架构设计，而轻详细设计。这里的概念

18、设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线 规划、市场趋势、客户价值、技术趋势等。架构设计，可以看成从整 体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不 同层次和组件之间关系是什么。详细设计，则是具体的设计和做法、 API接口等。2）SWOT分析在敏捷开发中，更加注重客户需求。如果对产品进行SWOT分析， 就能选出付出最小工作量，但能获得最大价值的模块。SWOT分析阶段会在概念设计和架构设计之后进行，输入是概念 设计和架构设计，输出是模块的重要度和需要的时间。这样按照性价 比可以进行排序，选出最能符合市场的模块。3）业务和客户驱动，而非技术驱动在产品的敏捷开发中

19、，虽说拥抱变化，但不盲目变化。产品的改 动需要经过概念设计、架构设计以及SWOT分析后，三思而后行。敏 捷开发中也强调”在整个项目开发期间，业务人员和开发人员必须天 天都在一起工作”，确保技术人员能够开发出客户需要的产品。4）时刻考虑版本兼容性敏捷开发，废除了过多冗余的文档和繁杂的设计，强调拥抱变化。 但作为产品，敏捷开发不意味着盲目地去变化。当设计变动、API接口重构、配置文件变更时，要时刻考虑产品 的架构、规划路线图，老版本的兼容性，及迁移平滑性。否则，随着 版本的增多，必将面对着大量的维护工作。5）轻文档，但非无文档敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意 味着无文档。在

20、敏捷开发过程中，适量的文档还是很有帮助，有助于 整理思路，加快沟通和讨论。我们产品中的文档包括：概念设计文档、 架构图、当前版本要实现的功能列表，以及SWOT分析。这些文档在 每个产品版本开始之前会有产生，在每个迭代的过程中根据业务人员 和市场的反馈也会有一些变更。通过我们实践证明，这对产品的思路、 沟通讨论都非常有帮助。而且这些文档，大多是几页PPT,书写和维 护工作都很小。敏捷开发的优点，下面是其中几点：1、市场和需求驱动，拥抱变化在产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示会, 把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收 集反馈。此外，在开发的过程中，产品的业

21、务人员和售前时刻保持与 产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。2、充分利用资源和时间采用敏捷开发，迭代开发、强调沟通、缩减文档，在每个迭代初 期就可以充分地利用开发、测试人员的时间，达到效率最大化。3、充分自动化敏捷开发强调拥抱变化，这必然带来动荡的产品代码变更。每一 个新的功能和修改的功能，都可以影响到其他功能，造成副作用。所 以，需要自动化去支持变化，在变化的同时保证质量和开发速度，包 括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、 集成测试自动化等。在IM客服项目中，XXX信息技术有限公司将在开发过程中充分 运用敏捷开发的理念，使得开发过程得以缩短以

22、满足民生要求内提供 试运行版本的需要；同时，适当加快版本迭代发布的周期（前期为1 个月，中后期为1周），使得迭代产物能更加趋近用户的需求，拥抱 变化而非死板地按照前期拟定的需求一直开发到提供初验版本。力争 在最短的时间内交付包含核心功能的可运行版本。1.3.3版本迭代模式在实际操作中，我们将不拘泥于MSF和敏捷开发的标准要求，而 是根据实际情况加以应用，如下图所示:在本次项目中，我们根据项目的实际开展情况，设置如下方式:1、负责构思和架构设计的人员可以与开发、测试人员并行地工 作，从而使人员的使用效率提高，开发进程得以缩短。2、动态的迭代周期，使得初期版本推出时的无效、重复的交互 得以减少，减

23、少了对业务人员的压力，提高了工作效率。项目进度管理本项目将由经验丰富的项目经理领导项目组并控制项目进度，包 括设计、实施进度及满足各种需要的进度计划的编制、检查；实施 方案的制定与实施，经常性地对计划进度与实际进度进行比较分 析，并及时调整计划等。1.4.1项目进度规划T：合同签订时间序号工作内容完成时间备注1QQ客户端页面 联动子系统开 发T+2个月2微信客户端营销服务子系统开发T+2个月3消息处理子系统开发T+2个月4客服子系统开发T+2个月5知识管理子系统开发T+2个月6运营管理子系统开发T+2个月7网服子系统开T+2个月发8报表子系统开发T+2个月9外部接口子系统开发T+2个月10硬件

24、及网络环境到位T+2个月硬件要加电、相 关的网络要具 备平台要求的 条件11部署及联调T+2.5个月12平台培训T+2. 75个月13平台上线T+3个月1.4.2项目进度控制为确保上述进度的实施，双方建立定期的工程联络会制度，以及 时协调、解决各个阶段出现的有关问题，具体细节待谈判时由双方商 定；在实施开始前，XXX信息技术有限公司将会提供总体项目进度 计划表及分项进度计划。从设备安装、验收、验收、交付、设 备维修等都制定详细的时间表。明确项目各阶段划分，设置项目分阶段完成检测点，以控制每 个环节的按时完成。深圳市XXX信息技术有限公司信息网技术有限公司项目经理 负责汇总项目阶段性工作报告，同

25、民生项目经理一起审阅。撰写项目进展和状态报告计划。具体实施如下：项目施工进度控制是项目管理的中心环节，在整个目标控制体系 中处于协调和带动其它工作的主导地位。是保障按时完成任务，合理 安排资源供应的重要措施。1、项目开局，编写项目开发计划，XXX信息技术有限公司将首先 安排和重点做好下列几件事：明确各人员职能、职责，落实与民生各子系统负责人等相 关人员、单位的联络方式，以便各方协调配合。抓好系统深化设计，制定合理的分期设计计划，以控制设 计、实施两不误。2、进度计划细化及管理，细化实施计划，将规定的任务结合在 线客服平台业务需求，在集成开始前和过程中不断地细化、调整计划， 使项目进度计划更具体

26、、切合实际和可行。做好进度记录、及项目中 的调度等工作。项目质量管理如前所述，本项目釆用MSF和敏捷开发相结合的过程模型，在开 发过程中，需要釆取一定措施对代码质量进行管理。1.5.1质量管理体系建立并不断完善质量管理体系，是整个质量管理的核心内容，它 将为质量保证活动奠定一个坚实的基础。这个管理体系是由五个质量 保证系统组成的：一、组织架构的保证体系。这个组织架构应至少包括三个要素：1、最高层领导在这个组织架构中扮演的角色；2、全体员工参与的方式和参与的程度；3、专业质量管理人员的配备以及所扮演的角色。二、规章制度的保证体系。这个规章制度也至少包括三个要素：1、操作流程的规范制度；2、信息管

27、理的规范制度；3、检验程序和变更程序的操作规程。三、质量标准的保证体系。建立这个质量标准体系的原则有三条:1、必须有精确量化的质量指标；2、必须有具体明确而不是抽象含糊的质量要求；3、实施操作的细则需要有统一的术语说明。四、资源配置的保证体系。资源配置至少包括三方面的要素：1、设备要素，配备必要的质量检验设备，并保证生产设备本 身的质量；2、原材料要素，建立质量认证体系保证原材料供应链的质量 标准；3、人才要素，选择、配备、培训合格的质量管理专才。五、持续改进活动的保证。持续改进活动的内容并无定势，但一般都包括培训、检查、评比、 问题分析、征集建议等活动。1.5.2质量管理措施配合上述五个质量

28、保证体系，制订相应的质量保证措施如下：设置质量保证组织架构最高层领导对项目最终质量负责，他可以充分调动资源并强力推 行质量目标。项目组每个成员对自己的产出物负有质量责任。配备专业的测试人员对程序开发的产出物进行测试，他们对程序 最终的质量起到把关的作用。制订完善的程序管理规章制度项目将采用统一的版本管理服务器管理项目源程序，每个人的程 序，必须经另外一个程序员检查后才能Check in,每天晚上都有 bu订d所有程序，如果bu订d不能通过，程序员必须立即修改自己的 程序。每隔一段时间配合进度里程碑release 个内部版本。这样做 的主要优点：从开始程序就是一个整体，而不是到最后才整合在一起;

29、 互相检查才能Check in可以减少错误的发生。设置明确的质量要求和测试过程质量要求的准则是客户导向的准则，就是以客户为中心，把客户 的满意度作为质量标准的尺子。这是ISO-xxxx体系的首要原则：鉴 于顾客是组织的存在之本，因此组织不但应该了解顾客当前的需求, 而且要了解其未来潜在之需求，不但要尽力满足顾客的需求，并争取 超越顾客的期望。测试过程是质量控制的重要环节，每一个版本的发布，都必须经 过测试人员的测试，提交测试报告通过审核后才能发布。配置充足的人力资源确保代码质量持续的版本迭代使质量不断改进螺旋式的过程模型使得每一个版本的推出都能够吸收和改进前 一版本存在的缺陷，从而使程序的质量

30、得到不断的改进。1.5.3质量控制流程质量控制流程采用PDCA流程法。PDCA是四个英文词的缩写，分 别代表质量控制过程中的四个环节：Plan是计划，制定质量管理的目标、要求、流程、制度等；D。是执行，实施质量管理计划，给予组织、标准、规章、资源等方面的保障；Check是检验，对照计划检查实施结果，发现缺陷及偏差并寻 找原因Action是处理，对缺陷和偏差进行规范化处理，对无法进行 规范化处理的，需要对流程及计划进行调整。然后调整措施又 将被纳入下一轮新的计划，形成一个循环往复的闭路流程。质量控制的PDCA流程贯穿了质量管理中四个最重要的概念：预 防、保证、检验、纠偏。预防和保证是为了将缺陷排

31、除在过程之外, 检查和纠偏是为了将缺陷排除在送达客户之前，PD着眼于预防和保 证，CA着眼于检查和纠偏。1.5.4项目变更管理在线客服平台项目的设计、开发、测试、推广全过程中，需要控 制来自小组内部或外部发生的，有关系统需求、功能、环境、资源、 时间等方面的改动、变化。对其影响力进行评估、权衡，与提出变更 人员、处理的有关人员协商，做出处理决定。变更控制参与人员包括：PDM（产品经理）、PGM （程序经理）、工 程顾问组成工程变更控制小组。变更控制小组责任：1、让每一位相关成员了解变更带来的对自己及别人的影响;2、综合各方意见并作出结论；3、确认受到影响的具体成员，并提出变更处理方法、时限;4

32、、PDM（产品经理）或PGM （程序经理）要跟踪变更的实现, 及更新受影响的有关文档；5、对工程建设全过程中产生的变更信息进行搜集；6、项目在需求分析与设计阶段时，变更可以随时进行评估, 但其它阶段要对接受变更与否进行权衡；变更处理前提：1、不能影响系统总设计目标及本次工程目标的实现。2、变更及其处理属于项目建设小组工作范围。3、项目领导小组要尊重控制小组的决定，外部或内部变更的 提出需经过控制小组。建设小组所有成员要服从控制小组的决定，不 能未经控制小组处理，擅自实现变更改动。变更处理流程情况内容结论时间参与人员1.变更提出的书面描述变更原因、性质、内容、处理建议变更提出后2小时内变更提 出

33、人员向变 更控制小组 提交2.变更报告的评估、讨论变更版本、理由、影响、代接收变更报告后4小时内变更提出人员、变更与协调价及好坏处控制小组、处理人员3o变更处理决定变更处理方法，实现程度要求，时间安排讨论后2小时内变更控制小组40变更处理跟踪监控实现程度，时间处理决定下达后，规定时间内变更控制小组5o变更归档变更档案的建立、相关文档的改动处理决定下达后1小时内变更控制小组1.6 项目沟通协调一个项目能否成功实施，沟通是否畅顺是关键。项目沟通是 确保项目团队的相关信息能及时、正确地产生、收集、发布、储 存和最终处理好项目信息所需的各个过程。为了确保本项目的顺 利实施，XXX信息技术有限公司将在项

34、目实施过程中提供良好的 沟通机制。1.6. 1沟通措施为了保证项目团队的有效沟通，我们提出了六项措施:建立沟通渠道，项目组实行每周一次的例会制度，通过例会达 到项目组各方充分沟通的目的。构建紧密矩阵，在空间上最大限度地缩小团队成员之间的空间 距离。在前3个月，开发人员和业务人员可以集中在民生办公, 集中在一个随时可以面对面交流的场所里办公，克服距离造成 的沟通障碍。保证沟通质量，在沟通过程中鼓励信息反馈，消灭晕圈效果、 虚假合意之类的无效沟通。用量化的信息代替那些“挺好、不 错、还行”之类的含糊其词。排除沟通障碍，针对团队中存在的主观沟通障碍，消除不良的 消极情绪，避免背后搞小动作，鼓励有话摆

35、在台面上说，用坦 诚对话解决问题。促成意见统一，最大限度地求同存异，提取公约数。把意见的 统一作为沟通的目标，以及衡量沟通效果的质量标准。筹备有效会议，会议是组织中最重要的沟通渠道，沟通的有效 性在很大程度上取决于会议的效率和效果。通过这六项措施，我们将确保本项目在实施过程中建设方和用户 方能紧密合作、畅顺沟通，最大程度地保证项目的实施质量。1.6.2冲突因素项目实施过程中，项目团队内部产生一些冲突是正常的，也是不 可避免的。关键的问题是要知道容易产生冲突的地方在哪里，产生的 原因是什么，以便尽可能避免冲突，或有效地解决冲突。下面列出的 是最容易产生冲突的六个领域，并不涉及项目决策时干系人之间

36、的利 益性冲突，主要指团队成员的工作性冲突。1、进度计划：主要表现在对工时和工期估算的意见分歧。有人想 把工期拉长，减轻自己的压力，但是你的工期拖长了，别人会有意见， 这意味着别人的工期要缩短，增加别人的压力。这归根结底还是时间 资源的分配问题。2、资源分配：供需矛盾是一对永恒的矛盾，不过管理中的供需 矛盾主要表现在各部门站在本位立场争夺资源而产生的摩擦，或者苦 乐不均产生的矛盾。3、优先级别：既然做什么不做什么已经在立项时就决定了，那 么项目的计划实施阶段的冲突就将主要表现在先做什么，后做什么的 争议上了。既然所有的决定都在资源约束的情况下进行，那么资源的 优先分配权的问题就变成了冲突的焦点

37、。4、技术观点：包括对于技术方案选择、质量标准认定、操作规 范效果评价等方面的观点分歧，原因可能是方法问题也可能是利益和 责任问题。5、行政导向：这方面的冲突涵盖面最为广泛，包括因立规、授 权、问责、奖罚、调度及管理方法而产生的各种矛盾。不按正常的指 挥链条进行沟通，例如下级的越级告状，上级的越级指挥，同级的越 权干涉，也是这方面冲突的高发领域。6、人际关系：指因个性不合而产生的感情矛盾。工作中的矛盾 一旦升级到了个人感情的冲突，观点的分歧就演变成为对人品的偏见, 这个结就很难解开了。人际关系的矛盾往往是非理性的，带有很强的 感性色彩，这是沟通管理中最大的陷阱，被称为管理盲区，或者管理 无能区

38、。因此，在处理工作冲突时，一定要坚持就事论事的理性原则， 避开个人情绪化，以免将矛盾升级到感性区。以上冲突不得到解决，将威胁项目的成功实施，因此必须在项目 开展过程中时刻关注冲突的发生并使之得到妥善解决。1.6.3解决冲突针对上面的冲突因素，可以有解决冲突的五种方式：1、强制执行，在双方发生冲突时，管理级别较高的一方以权压 人，命令对方服从自己的观点和决定。从坐标系的象限位置可以看出， 这种方式有利于解决问题，但是不利于后续的人际关系。被迫服从的 一方肯定口服心不服，冲突的根源并没有被彻底解决。2、主动解决，捅开隔在矛盾双方之间的窗户纸，通过面对面的 坦诚沟通交换意见，求同存异。这种方式既有利

39、于解决问题，也有利 于人际关系的修复，是这五种方式的上策。管理中人们经常犯的错误 是找错了沟通对象：丙明明是对甲有意见，却对乙说，结果一旦甲得 到了风声，就会认为丙在背后挑拨他与乙的关系，从而对丙产生成见， 矛盾的种子就是这样种下的。其实这件事情很简单，丙既然对甲有意 见，直接找甲说就行了，找乙说除了发泄情绪能解决什么问题？这种 发泄情绪的做法，恰恰会陷入感情冲突的非理性区。3、调和斡旋，当矛盾冲突陷入僵局的时候，聪明的办法是委托 一个斡旋人出面解开死结。扮演这种角色的人最好是德高望重、说话 有份量、且双方都可以接受的人物。这个调停人主要的作用其实只是 给双方台阶下。这种解决冲突的方式主要着眼

40、于缓和人际关系，但是 未必能解决问题，双方虽然保住了面子，但是问题仍旧存在。4、撤退回避，挂免战牌，脱离接触，把矛盾挂起来，留到以后条 件成熟了再解决。这就是我们常说的：让时间来解决问题。时间怎么 解决问题呢？从外因说，随着时间拖延，外部环境有可能朝着发生有 利于解决问题的方向变化。从内因说，时间可以腐蚀期望值，当双方 的期望值都降到了一个合适的位置的时候，解决问题的条件或许就成 熟了。这种方法对于解决问题和人际关系的效果都未必好，因为只能 被动等待。5、妥协折衷，就是用自己的主动让步交换对方的让步，用降低 自己诉求来交换对方降低诉求，以此来缓和冲突。这是一种不求双赢 而避免双输的做法。坚持主

41、张需要勇气，可是妥协更需要勇气。人们 常说：胜人者易，胜已者强。意思是说，战胜自己比战胜别人更困难。 用这种方式解决问题和缓和人际关系虽然不彻底，但表现了某种主动 积极的姿态，不失为一种可取的策略。五种方式各有优缺点，一般来说主动解决才是正解，但是在现实 生活中，往往也需要其他方式加以辅助，灵活运用。总之，XXX信息技术有限公司将在项目实施过程中，本着客观真 实、实事求是的态度，运用我们在与电信长期合作的经验，保持与民 生用户方的充分、深入的沟通，确保在项目开展过程中减少和避免冲 突的发生，即便发生冲突，也正视冲突，并通过沟通使得冲突得以化 解，从而确保项目的顺利实施。1.7 项目风险管理任何

42、一个项目在设定目标，实现计划的过程中都有可能出现一些 意外的情况，或许是技术上的、或许是资源方面也可能是时间安排上 的问题。因此在项目管理方案中包含了风险管理计划。风险识别和管 理计划从进程模型的第一个阶段就开始介入，是一种预风险管理方式。 不同于一般意义上的风险管理，风险管理强调的是防止风险的发生和 减少风险的损失，而不是在风险发生之后的补救措施。经过多年在实 践中的总结，大多数的风险都是可以预见和预防的。因此利用这种预 风险管理模式作为保证项目顺利完成的基础。项目组队模型中的不同 角色在不同的实现阶段分担不同的风险识别和管理任务，保证高风险 的情况应该得到优先的解决。结合项目制定的目标，配

43、合风险管理， 才能达到在指定时间内完成指定功能的目的。1.7.1风险评估风险管理首先需要定义风险，也就是评估风险。评估风险需要考 虑风险发生的可能性，风险的破坏力以及风险对整个项目的影响。在 正确评估了风险的基础上，需要考虑面对风险的对策，我们需要仔细 研究风险的各个方面，力求全面了解问题并确定风险的优先级，然后 考虑降低风险发生的方法，最后考虑风险发生时的对策。制定风险对 策之后则要做风险跟踪工作，通常我们会有风险计划的更新和跟踪、 每个阶段结束后的风险总结以及随时更新的当前最主要的前几个风 险的跟踪。整个风险控制在项目的风险管理之下，能最大限度的降低 项目失败的情况。下面是风险控制具体实施

44、的一个模板。在风险确定阶段就需要完 成最初的风险管理文档。风险管理文档的目的是详细的记录风险的性 质，而不是简单的一个名词而已。通过风险描述，要达到全面了解风 险的目的。最初的风险管理文档应包括：风险名称风险描述风险状况风险后果在最初风险管理文档的基础上可以对风险进行更详细的分析，并 最终在风险管理文档中增加对风险的分析信息。通过风险分析要达到 评估风险的目标，并分析补充风险的资料：风险源风险发生的可能性风险可能造成的影响风险的影响级别风险对整个项目的影响相关联的其它风险在本次项目中，XXX信息技术有限公司进行了初步的风险评估, 并按照风险级别进行了排序，主要的风险列举如下：1、时间进度风险。

45、本次项目时间紧、任务重，能不能在民生制 定的目标时间内完成相应的开发任务，是本项目最突出的矛盾和最大 的风险。2、程序开发风险。本次项目开发难度高，对开发人员的技能水 平、开发经验、协调沟通能力提出了很高的要求。3、资金成本风险。由于项目开发时间进度紧，需要在初期投入 大量的人力资源，后期维保时间又很长，需要长期投入人力维护，加 之还有第三方软件的采购，这些都给项目的资金成本带来风险，控制 不好的话，将使项目亏损，也有可能因此影响项目实施。1.7.2风险应对针对风险分析的结果，需要预先做好风险的应对计划。即如何防 止这个风险的发生，当风险发生时我们需要采取的措施。为此，当完 成风险计划的时候，

46、风险管理文档得到进一步的补充完善：预防风险策略预防风险策略评测针对风险需要采取的行动降低风险行动的最终期限负责此风险的人员风险时策略风险时策略评测和风险时策略的触发条件至此，风险管理文档针对可以预见的风险已经做好了预防等措施, 风险得到预先的控制和管理。针对前述对本次项目主要风险的评估，我们已经做好了预防风险 的准备：1、针对时间进度风险。首先是调配充足的人力资源进行项目的 实施，其次是采用分阶段的实施方式分期交付成果，在每一个阶段都 对需求内容进行风险评估，确保最需要的、最核心的功能优先得到开 发，从而加快系统的上线速度。2、针对程序开发风险。除了调配精兵强将投入本项目的开发， 团队内部加强

47、沟通和内部交流、培训也十分重要，通过充分的沟通统 一大家的认识，使得开发工作更为顺畅。3、针对资金成本风险。对投入的人力资源进行充分的考虑和计 划，例如采用重叠式的迭代开发，尽量提高人员的使用效率，一方面 要保证项目按时保质的实施，另一方面又要防止人力资源浪费导致项 目亏损。对于第三方软件则从一开始的计划就对采购成本进行计划和 控制，在保障民生业务需求的前提下减少第三方软件占用的资金成本。1.7.3风险跟踪风险的跟踪伴随在项目实施的整个过程中。根据风险管理文档， 可以得到当前优先级最高的前几个风险，并把这些风险作为跟踪的中 心。风险跟踪是通过风险跟踪文档来实现的。风险跟踪文档包括：风险项风险优

48、先级风险在跟踪状态下的时间风险管理目前的进行程度风险管理期中时间风险管理完成时间在风险跟踪文档产生的同时，还针对每个时间阶段（每个风险管 理期开始、期中和完成时间）形成风险状态表。风险状态表记录某一 个特定时间点上各个风险的最新情况，这些信息包括：时间风险项针对风险采取的措施风险的负责人措施前风险发生的可能性措施后风险发生的可能性措施前风险对项目的影响度措施后风险对项目的影响度当前整个项目的风险度（总计所有项目的影响度）在项目管理体系结构中，通过上面的风险描述、风险分析、风险 跟踪来达到风险控制的目的。从整个流程上可以看到，风险管理将预 防风险的发生放在显著的位置上。其次才是在风险发生时的处理

49、方案。1.7.4风险管理组织在组队模型的六个角色设立的方式中，充分体现了项目风险管理 的概念，每个角色都从不同的角度负责方面的风险识别和风险管理任 务：产品管理代表客户的需求，负责整个项目的整体目标和范围，保 证项目在实现的过程中符合客户的需求。避免资源方面的风险和产生 不符合客户需求的产品的风险项目经理则关注整个项目的进展情况，保证项目在预期的时间和 资源条件内顺利地完成所承诺的功能。避免技术方案方面和人员方面 的风险开发集中在技术细节和人员能力方面的风险，随时评估开发过程 中的细小阶段是否能按时完成，完成的部分是否符合要求等开发需要 避免在开发过程中影响完成符合功能规范产品的风险用户教育代

50、表最终用户的需求，负责保证最终用户使用的方便性, 是负责设计最终用户使用系统的界面和文档的小组，需要评估在用户 培训阶段要面临的问题，并提供解决的方法。避免最终用户在使用产 品时不能很快的适应新产品或者因为不能了解新产品的功能而造成 使用上的失误测试是保证最终交付的产品是解决了所有已知问题的产品。测试 要承担在测试阶段时的测试方案、测试环境相关的风险。避免交付的 产品不能达到最初的设计目的最后一个角色是推广实施，代表的是运行、支持和维护人员的需 求，负责产品在客户方的安装和设置，并保证将产品平稳的移交到产 品运行、支持和维护组手中。因此推广实施需要面临的风险是产品购 买、硬件方面和软件设置安装

51、方面的风险。7. 5小结项目的管理是围绕着资源、时间和实现功能三个方面。相应的风 险管理就面向于资源、时间和实现功能三个角度。这三者是一个三角 形的关系，任何两方面的能实现的范围决定了另一方面可以实现的范 围：例如能投入的资源（人力/物力/财力等）和开发所需要的时间决 定了应用系统可以实现功能的大致范围。因此在项目的目标/范围确 定阶段，就要根据三个方面能投入的力度来设置风险管理计划，当任 何一方面的投入发生变化的时候，需要修改相应的计划以避免项目的 失败。在随后的系统设计、开发、测试阶段不断更新风险管理计划， 保证在每个阶段的每种情况都有专人的负责和充足的准备，整个项目 所面临的风险都随时得

52、到关注和解决。对于大型的项目，还可以委派 专人负责整个风险管理的管理工作，以确保风险随时得到控制。风险 计划书对整个项目组和客户都是可见的，保证它能被实时更新和及时 跟踪。1.8 项目现场管理按照敏捷开发的模式，同时根据民生客服中心的要求，在整个项 目开发期间，业务人员和开发人员必须在一起工作。在项目实施期间， XXX信息技术有限公司可以将派出开发团队到民生现场驻点。现场驻点的人员包括：1、项目经理负责和甲方指定的产品经理进行沟通，了解并掌握用户的需求; 负责项目的总体进度控制、资源协调、质量控制、风险控制；负责对 项目组的现场工作进行管理，包括：人员管理、程序管理、制订项目 组工作计划、召集

53、例会和各种交流培训等；2、需求分析人员需求分析人员需要密切地和甲方的产品经理、业务人员、最终用 户进行密切的沟通，深入了解并确定需求的内容和范围。3、架构设计人员架构设计人员需要深刻地了解用户的需求，并将需求转换为可实 施、可开发的系统和程序的架构设计，架构设计人员有责任和甲方产 品负责人明确各个阶段需要完成的核心功能的范围、优先顺序，有责 任将架构设计的思路与各方沟通并得以明确。4、UI界面设计人员UI界面设计人员需要通过不断向用户提供原型设计，展示给用 户并根据用户的反馈进行修改完善。UI设计关系到最终用户的使用 体验，是产品最终能否方便、高效、易用的关键。UI设计人员还需要 和程序开发人

54、员密切配合，使程序开发人员深刻理解用户的操作，并 准确地实现相应的功能。5、程序开发人员在敏捷开发的模式里，程序开发人员除了完成程序的开发、自我 测试、程序版本和质量的控制外，很重要的工作就是需要和UI设计 人员、需求人员、乃至最终用户进行沟通，在深入了解需求的基础上 进行程序的开发工作。6、测试人员本次项目采用的螺旋迭代式的开发，版本的测试、发布会很频繁, 每个版本的发布都必须经过测试人员的测试，确保版本的质量，因此, 测试人员必须频繁地和开发人员沟通，反馈测试过程出现的问题，能 及时解决的就及时解决，暂时不能解决的则列入下一版本的开发内容 里。7、用户培训人员用户培训人员并非项目做完了给用

55、户做一次培训就完了，因为是 采用螺旋迭代式开发，在每一个版本发布的时候，新的功能都需要对 用户进行培训，使每一个版本所完成的功能都能让用户充分的理解并 顺利地使用。第2章测试验收方案2. 1验收标准1.1功能项测试对软件需求规格说明书中的所有功能项进行测试。12业务流程测试对软件项目的典型业务流程进行测试。1.3容错测试容错测试的检查内容包括：1）软件对用户常见的误操作是否能进行提示；2）软件对用户的的操作错误和软件错误，是否有准确、清晰的提示；3）软件对重要数据的删除是否有警告和确认提示；4）软件是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。1.4安全性测试安全

56、性测试的检查内容包括：1）软件中的密钥是否以密文方式存储；2）软件是否有留痕功能，即是否保存有用户的操作日志；3）软件中各种用户的权限分配是否合理。1.5性能测试对软件需求规格说明书中明确的软件性能进行测试。测试的准则 是要满足规格说明书中的各项性能指标。2.1.6易用性测试易用性测试的内容包括：1）软件的用户界面是否友好，是否出现中英文混杂的界面；2）软件中的提示信息是否清楚、易理解，是否存在原始的英文 提示；3）软件中各个模块的界面风格是否一致；4）软件中的查询结果的输出方式是否比较直观、合理。1.7适应性测试参照用户的软、硬件使用环境和需求规格说明书中的规定，列出 开发的软件需要满足的软

57、、硬件环境。对每个环境进行测试。2.1.8文档测试用户文档包括：安装手册、操作手册和维护手册。对用户文档测试的内容包括：1）操作、维护文档是否齐全、是否包含产品使用所需的信息和 所有的功能模块；2）用户文档描述的信息是否正确，是否没有歧义和错误的表达;3）户文档是否容易理解，是否通过使用适当的术语、图形表 示、详细的解释来表达；4）用户文档对主要功能和关键操作是否提供应用实例；5）用户文档是否有详细的目录表和索引表。2.1.9用户有特别要求的测试2.2 测试用例编写方案及标准2. 2.1编写原则（1）基本的原则就是：“一点多例”，就是针对一个测试点或 者功能点，编写多个测试用例，从多个方面进行

58、测试。各个部分的 用例编写的都贯穿着这一基本思想。（2）单元测试由开发人员执行，可以自身决定是否编写单元测 试用例。（3）对于每个用例事件流，测试需求的详细列表至少会包括一 个测试需求。对于需求规格说明书中的功能描述，将至少派生一个 测试需求。（4）测试项描述-简要说明测试用例所要涉及的项和特性、对 于每一项、可考虑引用以下文件：需求说明书、设计说明书、用户 手册、操作手册。（5）输入说明描述-规定执行测试用例所需的各个输入。有些输 入可以用值（允许适当的误差）来规定。而另一些输入，如常数表 或事务文件可以用名来规定。规定所有合适的数据库、文件、终端 信息传送的值。输出说明描述-规定测试项的所

59、有输出和特性(如：响应 时间)。提供各个输出或特性的正确值。测试用例的设计，始终要考虑测试的执行，同时测试发现 的问题和总结的经验也可以用来完善测试设计。2. 2. 2衡量测试用例设计的质量标准可测性：测试用例的所有步骤是可测的，测试的步骤是具体可实施后的，按照每个步骤是可以走通的。可验证：测试的每个步骤验证点是具体、可验证的。期望结果不是抽象的描述，而是可获得的。全面性：测试执行人员，无须考虑怎么测、而是参照测试用例 设计的步骤执行，测试数据的准备也要在测试设计时考虑，而且要具备高覆盖率和全面性。2. 2. 3测试用例与开发的对应关系约定开发阶段依据文档编写的用例需求分析阶段结束后需求文档系

60、统测试对应的用例概要设计阶段结束后概要设计、体系设计文档集成测试对应的用例详细设计阶段详细设计文档单元测试对应的用例备注：单元测试由开发人员进行，故不纳入测试用例。2. 2. 4测试用例类型约定测试用例对应测试类型测试 覆盖率 （测试人 员）功能测试用例主要包括功能测试90%100%性能测试用例性能测试、压力测试、强度测试10%集成测试用例接口测试、健壮性测试、可靠性测试40%50%安全测试用例安全测试10%用户界面测试用例用户界面测试、少量功能测 试100%2. 2.5测试阶段、类型与执行角色的关系约定测试阶段测试类型执行角色单元测试主要包括功能测试开发人员，测试人员可配合部分基础数据准备集