MSF实施方法论

《MSF实施方法论》由会员分享，可在线阅读，更多相关《MSF实施方法论（30页珍藏版）》请在装配图网上搜索。

1、1 MSF项目管理体系在本项目的实施过程中，XX公司将采用微软提出的微软解决方案体系（Microsoft Solutions Frameworks，简称MSF）来执行对项目的实施管理。微软公司在产品开发过程中，发展了适用于自己的项目管理方法，再结合从合作伙伴以及客户方面总结的经验而形成了一种用于项目管理的解决方案，这就是微软解决方案框架（MSF）。MSF是一套大型系统开发指南，其成熟的项目实施详细框架能有条理地组织项目实施各个阶段的项目活动，描述工作步骤、任务和每一阶段的项目里程碑，引导项目走向成功。作为微软的金牌合作伙伴，XX公司采用了这种管理方案，把MSF的项目管理方式应用到为客户设计、构

2、建和实现商业应用的顾问咨询服务中。采用MSF的项目管理模式，能够使工作流程更加有效，提高快速反应和决策能力；开发者和用户的交流更加紧密；能更高效的使用客户/服务器结构来支持企业日益增长的商业运作等。此外，MSF是建立在软件开发的工业化的基础上，从而能更加切合软件开发的基本原理，减少开发过程中出现的问题。这些都是传统软件开发模式无法解决的问题。而在MSF中，实现客户的商业目的是整个MFS管理的核心，整个开发过程都围绕这一目标去展开和细化。MSF是一项实践性非常强的复杂的管理过程，是一种观念的传播。具有决策或是可以影响决策的人士接受了这样的观念，MSF就有实施的可能，整个项目才可能进一步得益于MS

3、F。MSF使用两个模型和三个准则来管理应用程序的开发，如下图所示。图：MSF的模型和准则MSF团队模型用来组织人员执行项目工作，将团队的每个角色和一个主要的项目职责联系起来，保证实现所有的项目目标。MSF过程模型通过安排时间、将过程分成一系列由里程碑标记的独立阶段来组织过程，从而创建并交付一个解决方案。MSF项目管理准则保证项目管理活动是流水线型的，这些活动能够帮助而不是阻碍团队取得成功。MSF风险管理准则预先准备好处理风险的办法，将意外事件、“救火”及其他代价巨大的行为发生的可能性降到最低。MSF就绪管理准则预先确定团队针对项目需要的技能。在MSF中通过这两个模型和三个准则，并配合Micro

4、soft的工具和技术，就能够建立并完成分布式企业应用系统的开发和部署。这些经验和准则在实践中被证明是十分成功的。1.1 项目组队模型在微软的项目管理方法MSF中，组队模型着重于解决在复杂软件工程项目中如何组建项目组、如何分配合适的角色、管理项目组、划分职责和控制质量等问题。MSF将项目组的成员分为6个角色，组成高效的项目组。在项目组中每个角色都明确他们各自的职权和目标。明确的责任与权力会消除获得成功过程中的障碍，并使项目组成员专注于自己的工作目标。高效的项目组能够保证项目的目标和进度的安排，保证目标和进度的相互配合。项目组中的每个成员都需要理解客户和最终使用者的需求，这样他们就能够基于使用者和

5、客户的期望作出良好的决策，并根据他所负责的任务进行时间、进度的估计和安排。MSF组队模型由以下六个明确定义的角色组成：图：MSF组队模型1.1.1 产品管理产品管理负责为本阶段应用系统项目的开发确定一个目标，通过与客户的交流明确客户的目标并形成面向项目小组的需求说明。这种角色的目标是确保清晰地表述客户的要求并控制客户的期望值，使其为整个项目组所理解，使得功能说明和系统设计与客户的业务优先级相吻合。1.1.2 程序管理程序管理是一个交流与协调的角色。需要完成基于应用系统的业务需求文档以及目标和范围文档，设计、管理和维护程序的功能说明。程序管理负责所有与分析、定义系统结构的管理任务。在开发人员的配

6、合下，程序管理必须确保功能说明在现有的资源（时间、人力）下，技术上是可以实现的。程序管理需要具有很强的技术能力，以便与开发人员相配合作出关键的决策。他们需要理解项目体系结构的实质，他们常常是项目组中最有经验的成员。程序管理必须跟踪负责整个项目的进展。1.1.3 开发构造和实现满足规定的应用系统。开发这种角色是负责交付一个完全满足功能说明中的应用系统。也是整个应用系统项目中代码的主要完成者。1.1.4 测试测试的任务是保证应用系统交付之前，能够发现所存在的问题。测试要准备测试计划、测试规定和测试的案例，这些文档用于有计划和目的地进行测试。测试这种角色必须独立于开发，而且测试不仅仅是代码方面的，同

7、时它还还应用在功能规定、系统的性能、用户界面和系统实施等方面。1.1.5 系统实施系统实施的任务是确保应用系统平稳地过渡、安装和移交到用户运行环境以及和技术支持组。角色任务包括：系统的日常管理、局域网和服务器的管理；灾难恢复计划；技术支持计划；用户注册和帐户管理；系统安装和故障检修；跟踪系统性能增强的要求和记录系统故障的情况等。1.1.6 用户教育用户教育的任务是通过应用系统的演示和培训，尽可能地使最终用户在使用系统时能充分利用系统所提供的功能。用户教育的第二个任务是通过编写使用文档，使应用系统更容易被用户理解和使用，降低整个系统技术支持的费用。作为系统的最初使用者，用户教育应参与系统和用户界

8、面原型的设计和构造，也参与包括程序的安装部分的设计。伴随系统的开发过程，用户教育要根据开发进度完成文档或电子联机文档。如果需要的话，用户教育还要准备并交付系统的培训材料。微软建议项目组人员的组成和各类成员的职责如下：角色责任主管领导该角色由高层主管领导担任。该角色对项目的最终成败负有责任。在项目进行过程中，该角色有权力对用户方进行协调，代表用户方做出决定，支持项目组的工作。该角色需要时才出现。程序管理该角色按周检查项目进展情况，并进行项目的日常管理，协调项目组的工作，报告项目进展情况。微软方和用户的项目经理每周将花2-3天时间进行这项工作。产品管理由最终用户或懂业务的人员担任这一角色，在项目进

9、行的全过程中，始终代表着最终用户的利益，反映最终用户的要求。担任这一角色的人员可以不是技术人员。开发组开发组在项目中负有如下责任：充分了解技术环境在项目的整个生命周期中设计、开发、模块测试测试组规划和进行新系统的测试用户教育保证最终用户在使用系统时的方便性，负责与最终用户沟通进行操作方面的要求，负责用户界面设计的合理性，准备最终用户的培训教材，并进行最终用户的培训工作。该角色评估各种培训方式，挑选合适的培训项目。系统实施该角色规划和进行系统的安装实施，完成硬件和软件的规划、定货、采购和安装。1.2 项目过程模型项目实施过程如下图所示：图：项目实施过程MSF过程模型共有五个阶段，每个阶段最后都对

10、应一个主里程碑。 在构思阶段，团队、客户和发起人对项目概要性的要求和目标进行协商。 在计划阶段，团队和客户共同定义构建和部署的内容以及构建的方式和时机。 在开发阶段，团队构建并测试解决方案，具体包括代码、基础架构和文档等交付成果。 在稳定阶段，对功能齐全的解决方案进行最后的测试，使其成为稳定的解决方案，为其后的发布做准备。 在部署阶段，将稳定、完善的解决方案完全部署为真正的产品。使用MSF过程模型具有以下好处： 使用过程模型提供的组织结构后，团队可以把精力集中于解决方案的开发上。 解决方案是根据业务目标和需求开发出来的，而且在整个项目生命周期中，解决方案的测试也是根据这些目标和需求进行的。 项

11、目状况以及解决方案的质量对于客户和干系人来说是可见的。 过程模型可以使项目平稳地过渡到运营阶段。MSF这种以目标为管理核心的模式能建立良好的项目队伍，使各自发挥所长、各尽其责，以里程碑方式驱动整个项目的滚动前进。在实施中注重项目各阶段的结果，在项目管理过程中及时地进行风险评估和控制，能大量地缩短项目的开发周期，已经在实践中被证明是一种快速开发的方法。1.3 进度管理进度管理将作为一项日常的正式的项目管理活动纳入日程，需要项目管理组和各子项目负责人的共同配合来完成。1.3.1 进度计划的制定各个子系统在完成系统设计后，应该制定详细的项目工作进度，工作安排的详细程度应该在每一个可单独跟踪的功能模块

12、级别上，并已经分配给具体的人员。项目管理小组使用该任务资源在开发域中的域帐号作为任务分派的对象。举例如下：项目组成员：域帐号：任务：制定项目管理计划工期：3天Project设置为（图1）：1.3.2 进度的跟踪任务进度报告项目组成员必须每日提交工作进度报告，工作进度报告分为两个部分： 任务完成状态日报通过进度跟踪系统每日（工作日结束时）填写任务完成的情况，基于当前完成情况对于剩余工作量给出真实的估计。该日报必须每日执行。（具体操作参见项目开发环境使用手册进度跟踪系统部分） 工作报告日报通过进度跟踪系统每日（工作日结束时）填写任务进展的说明。该日报在任务进展发生了延迟或出现重大问题时需要填写提交

13、，如果任务顺利执行，该报告可以不填写。（具体操作参见项目开发环境使用手册进度跟踪系统部分）被分配任务的项目组成员从项目进度跟踪站点上得到其任务分配：如果没有特殊原因，必须接收该任务并回复，或者拒绝并回复原因。在接下来执行的过程中，需要每天提交对于该任务的完成报告。小组汇总所有的进度报告，并根据该数据更新项目进度，作出项目进度图表1.3.3 进度评估与报告将项目组提交的进度计划作为比较基线，根据项目组成员提交的进度日报同步更新，对实际执行情况和计划进行对比，给出项目进度报告，对于出现的任务延迟迹象及早发现，同时对于项目进度状况进行分析。1.4 质量管理本次项目中采取在各里程碑审查的方式进行质量保

14、障。在XX公司项目实施小组中，所有成员都要对产品的质量负责。以下内容是对项目各阶段成果进行审查的规范。1.4.1 审查的内容类型审查项目先决条件所需资料需求系统需求分析说明建立审查规范系统需求分析报告已经定稿系统需求分析报告需求检查表设计系统设计说明建立审查规范系统概要设计已经定稿系统详细设计定稿系统概要设计报告系统详细设计报告系统设计检查表编码*源代码模块建立审查规范已经选取了需要进行审查的代码源代码列表系统开发手册编码规范代码检查表BUG数目系统测试结果系统已经开始进行测试测试统计数据确认测试测试程序建立审查规范系统测试计划已经定稿系统测试方案已经定稿测试计划测试方案系统需求分析报告测试检

15、查表*对于编码由于时间和资源的限制可以不在项目总体的级别上进行审查1.4.1.1 需求检查表n 综合业务情况 所有调研工作均已结束 汇总业务调研的结果（环境/过程/操作/数据） 项目组成员都已清楚业务调研的结果n 建立当前业务执行描述 业务执行的企业及物理环境 按照业务过程归类业务执行（过程） 每一类业务过程得出其业务活动环节(活动) 每一个业务环节得出其具体任务序列（任务） 每一项任务执行的各个步骤（步骤） 每一个步骤上应用的业务规则和执行的业务操作 用户对业务执行功能的使用需求 业务和外部支持系统之间的关系n 建立当前业务数据描述 业务对象 业务对象的属性 业务对象的状态 业务对象之间的关

16、系 业务对象的来源 业务对象的去处 需要外部支持的数据n 改进优化当前业务执行 提出并讨论对业务过程的改进意见 提出并讨论对业务操作的改进意见 就业务改进优化和客户方达成一致意见n 验证业务分析结果 需求分析结果已经初步确定 项目组已经就需求分析结果达成一致意见 用户方业务直接负责人参加验证工作 用户方业务执行人员参加验证工作 用户方同意项目组对业务的理解1.4.1.2 概要设计检查表n 建立系统逻辑模型 从业务场景中列举全部可能候选的对象 从业务场景中列举这些对象的属性 从业务场景中列决全部可能候选的服务 归类服务的类型：界面服务、业务服务、数据服务 分析候选服务：服务应该属于一个唯一的候选

17、对象 分析候选对象：对象至少应该提供一个服务 获得最后的对象、服务列表 建立系统组成部分（如子系统）结构框架n 优化系统逻辑模型 分析可能隐含的对象或者服务 对对象服务列表进行优化（合并/取消/调整） 定义对象之间的交互时序 使用对象和服务建立系统流程n 建立数据逻辑模型 从业务数据描述获得候选数据对象及其属性 从系统逻辑模型中获得候选数据对象及其属性 确认每一个数据对象都至少在一个服务中被使用 获得数据对象列表n 优化数据逻辑模型 分析可能隐含的数据对象和属性 优化数据对象和属性列表 确认每一个服务操作的数据都已经被表示 确定数据对象的状态转换n 验证系统逻辑模型和数据逻辑模型 项目组全体成

18、员讨论并达成关于系统模型的一致意见 将系统逻辑模型和数据逻辑模型和业务场景进行覆盖性检查n 确定项目技术实现方案 界定项目所涉及各个技术点 就每一个技术点比较可能的实现方案 项目组讨论对各个技术点实现达成一致意见n 建立系统物理模型 建立系统层次结构 划分系统功能模块 定义系统服务接口 定义系统组件对象 定义各个功能模块实现规范（输入/输出/处理/规则）以及关系n 建立数据物理模型 定义数据库表结构 定义数据库访问接口（视图/存储过程） 定义外部数据接口方式n 确定应用发布模型 组件的包组织文件 各个功能模块的组织文件 检查系统发布模型和功能模块的对应n 确定系统部署结构 确定系统各部分的逻辑

19、部署结构 且定系统的物理部署结构 检查物理部署结构和逻辑部署结构的对应n 制订程序开发进度 确定系统各功能模块之间的依存关系 估计每一个功能模块完成所需要的时间 分配任务给开发人员 每一个开发人员都清楚自己的任务并且没有困难n 评审系统设计方案 项目组已经就设计方案达成一致意见 邀请客户方面和项目相关的技术部门人员 向评审会出席人员介绍系统设计方案的每一个重大方面 全体人员就项目技术方案达成一致n 制订测试计划 安排测试项目 检查测试项目和系统功能特性的覆盖性1.4.1.3 详细设计检查表n 建立代码开发规范 制定代码命名规范 制定技术实现规范 全体开发人员了解开发规范n 定义各功能模块的实现

20、方式 定义所有功能模块算法和程序流程1.4.2 审查的方式在每一个阶段里程碑（分析、设计、编码）召开项目审查会议，分别和各个项目组进行相关内容的审查。1.4.3 参加审查的角色 主审员由客户项目高级管理经理和XX公司项目顾问担任。负责协调召开审查会议，召集相关人员，督促准备审查所需要的资料。主审员的职责主要有：u 选定审查组成员u 确保项目经理了解审查工作u 制定审查会议计划并对会议资源作出必要的安排u 确保审查组充分做好准备工作u 确保审查会议高效有序进行u 确保审查会议上找出的问题已文档的形式记录在案u 跟踪每个确定的问题直到问题解决u 审查会议后两个工作日内准备和分发会议记录 责任人由接

21、受审查的子系统负责人担任。其职责主要有：u 确保要审查的工作已经完成u 按时提交所需要的信息u 帮助主审员做好会议安排，提供资料u 及时解决审查组确定的问题u 坚持客观性，避免辩解 讲解员由接受审查的子系统方面项目经理担任。负责对提交的工作进行解释。其职责主要有：u 完全熟悉提交的工作u 确定信息的逻辑关系并能解释每一个条目u 支持主审员的工作 审查员由各子系统项目经理担任其他接受审查子系统的审查员是一个很好的选择。其职责主要有：u 评估提交的工作产品u 侧重于鉴别问题而不是解决问题u 保持客观性u 对工作而不是对个人发表意见u 支持主审员的工作1.4.4 审查过程1.4.4.1 计划 目标u

22、 确定需要审查的工作u 确定需要审查的工作已经可以进行审查u 确定审查小组 活动u 确定需要审查的工作u 确定审查小组u 主审员需要确保审查小组了解审查的过程u 主审员将会议日期、时间和地点通知审查组成员。u 主审员和责任人确定审查所需要的资料，并确保在会议前至少两天分发这些资料给审查组成员1.4.4.2 准备 目标u 通过严格审查工作成果和评审资料来做好审查会议准备工作 活动u 审查员评估工作成果并写下自己的意见1.4.4.3 审查会议 目标u 确定正在审查的工作成果中存在的问题 活动u 审查员介绍在准备阶段自己对于审查工作成果的意见u 责任人和讲解员可以就问题和意见陈述自己的看法u 记录最

23、后经大家讨论后确认的问题1.4.4.4 追踪 目标u 确保已经采取了改正措施来改正审查期间发现的问题 活动u 责任人和主审员就落实改进措施的计划安排方面达成一致意见u 责任人解决审查组确定的问题u 当修改工作完成时，主审员审查修改工作1.5 风险管理风险管理将作为一项日常的正式的项目管理活动纳入日程，需要项目管理小组和项目成员的共同配合来完成。IT项目由于其规模大和复杂性等特点，在实施过程中存在着不确定的因素，比一般产品生产具有更大的风险，进行风险管理尤为重要。XX公司风险管理遵循微软MSF风险管理体系。1.5.1 风险管理模型五步风险管理是一个生命周期过程，该过程中包括： n 评估风险可以使

24、项目组将隐含的风险提出来，在风险发生并危害项目对其控制，防止风险危害项目。n 分析风险对评估活动中提出的风险项目进行分析，确认其各个风险要素，使项目组以及客户作出相应的决定n 在对风险进行了分析的基础上，需要将作出的决定和措施成为正式的风险计划使项目按照计划安排活动n 在风险计划制定后，需要密切注视在计划中所列举的风险因素的变化情况，并在风险出现时采取措施n 风险控制需要把对风险的管理纳入日常的项目管理活动。1.5.2 风险计划风险计划是评价、识别并分析潜在风险区域的过程。可以通过列举通常的软件项目风险因素以使风险识别更加明析。制作风险评估表是识别风险的好办法，在风险评估表中我们统计特定风险对

25、项目可能造成的潜在后果。风险计划的要素有：n 风险描述：对于风险情况的介绍。n 可能性：风险发生的可能性。风险不是必然要发生的，如果一个对项目存在危害的事件是必然要发生的，那这个事件就不能作为风险。对于风险可能性的标识有助于对那些高可能性的风险投入更大的关注。n 严重性：风险如果发生对于项目的危害程度。n 危害值：一个综合考虑可能性和严重型后对风险的一个评估，这个评估反应了风险应该被关注的程度。n 对策：对策分为两个部分：一是对于采取预防措施以阻止风险的发生，另一方面也要考虑如果风险发生后需要采取什么措施。这两方面的计划构成了完整的风险对策。n 触发标志：风险是一种可能性，并且制定风险主要的出

26、发点是预防它，但也要考虑到风险发生后情况。对于风险发生后的应对策略，需要争取一定的提前时间以启动必要的各项工作，设立触发标志是为设立一个判别标识，在该触发标志所标明的条件具备时，说明风险已经越来越可能成为现实了。n 风险责任人：风险预防和跟踪需要有人的参与，在风险计划中责任明确是一个重要的原则，对每一个列入了视线的风险都要指定对风险预防和跟踪负责的人员。风险计划不是一个静止的文件，它应该随着项目状况的变化而变化。所以在任何项目中，风险管理都必须被作为一个日常的正式活动列入项目工作计划，成为项目管理人员的一个重要工作。在标定风险可能性和危害时，重要的是清楚地标明风险之间重要性的相对比较，所以采取

27、一个简明的标注标准十分重要。1.5.3 管理过程u 项目组在每周一提交风险报告u 项目管理小组将项目组提交的风险报告作为跟踪标准u 在每周五由项目管理小组协调召开风险复查会议。在风险计划中按照风险危害值排序，关注的风险一般不超过10条（Top10）：u 风险可能性：1可能性很小2可能性一般3可能性很高u 风险危害性：1影响很小2影响一般3影响很大u 风险评估值：风险评估值风险可能性风险危害性1.5.4 项目风险因素检查表使用以下表格进行风险检查。项目相关的风险要素及分类用户角度的要素及分类编号风险要素低风险中等风险高风险等级客户的任务和目标1项目是否符合客户的目标完全符合客户的目标一个或几个客

28、户的目标不能直接实现基本不能达到客户的目标2对客户原有工作流程的影响基本保持客户原有的工作流程某些工作流程会因为本项目而受到小的影响客户的工作流程和方法将因本项目的实施而产生很大的变化客户的机构管理3客户机构的稳定性基本不会发生变化会发生较小的变化客户的机构或管理方式会发生持续的或迅速的变化4客户机构中的人员及责任每一个人都很清楚自己及他人的角色和工作责任每一个人都清楚自己的角色和工作责任，但并不清楚其他人的责任客户机构中的大多数人都不清楚自己或他人的工作职责5政策和标准有详细的政策与标准并严格遵守有政策与标准，但没有很强的约束力没有政策或标准，或制订不正确而没有执行6管理层的支持强力支持本项

29、目的成功有一些承诺，但不完全支持几乎不支持本项目7执行层的支持有很强的支持当被要求时，有有限的支持没有有效的支持8项目目标需求合理，目标有效有一些项目目标，但衡量标准有一些问题没有明确的目标，或目标无法衡量9做出决议的流程决议可以由一个负责人或一个固定的小规模的团体作出决议必须在固定的例会上由领导层决定决议由一群管理人员作出，但这些人员没有固定的决议方法，也没有领导人员10客户的衡量标准对业务是否成功和信息技术对业务的影响，客户有成熟的衡量标准IT客户对业务的某些方面有衡量标准，但可能没有标准衡量信息技术对业务的影响几乎没有标准来衡量业务及信息技术对业务的影响11客户组织成员的参与程度项目组可

30、以与客户所有需要交流的部门进行足够的交流项目组不能确认是否能够与所有需要交流的部门进行足够的沟通项目组与客户组织中的一个或数个关键部门进行交流，或这些部门之间没有交流，或项目组与某个关键部门的交流将影响项目组与其他部门的交流客户/最终用户12最终用户在项目中的参与程度最终用户紧密参与项目开发，并有重要的作用最终用户在项目中扮演次要的角色，对项目的贡献为中等程度几乎没有最终用户的参与，最终用户对项目也几乎没有意见和建议13最终用户的使用经验用户在类似项目上有丰富的使用经验，对如何达到需求有明确的思路用户有类似系统的使用经验，并且有关于需求的想法用户几乎没有任何类似系统的使用经验，也不知道如何达到

31、需求14最终用户对项目的接受程度用户完全接受系统的概念和细节，认为处理流程是适合需求的用户接受系统的大部分概念和细节，认为处理流程是适合需求的最终用户拒绝接受系统的概念和设计细节15最终用户的培训需求培训需求已被充分考虑，培训工作正在进行或已有合适的计划培训需求已被充分考虑，但培训工作没有开始并且没有合适的计划培训需求没有被考虑过16最终用户在项目涉及的领域中的知识最终用户对项目涉及的领域有相当的知识和经验该领域对最终用户相对较新，但已经开始对他们进行适当的培训用户对该领域几乎没有任何认识，并且没有计划好的培训工作17最终用户之间的相似程度绝大多数用户有着相同的背景，并且会用相同的方式使用本系

32、统用户将使用一些已经定义好的流程使用系统用户使用本系统的流程可能是多种多样的客户的技术部门18客户组织吸引和留住员工的能力客户能够招聘到并且留住有足够技能的员工，并对技能不足的员工进行适当的培训客户能够招聘到有限数量的有足够技能的员工，可能需要支付额外的奖金很少人愿意在客户的组织中工作，客户也因为员工的频繁流失而不愿意对他们进行培训19人力资源管理经验客户在人力资源的管理和发展上有很强的经验客户在人力资源的有效管理上有成功和失败的记录客户没有能力保留住好的员工和管理人员20临时员工的雇佣客户仅仅偶尔雇佣临时员工作为固定员工的补充客户有一些临时员工，主要目的是传授技能给固定员工客户组织中有大量的

33、临时员工，并且几乎没有技能转移的工作项目角度的要素和分类项目特征21项目复杂度项目较小，不很复杂，或很容易分解项目规模中等，复杂度中等，可以被分解大型项目，高复杂度，难于分解22硬件限制几乎没有硬件限制，单一系统平台有一些硬件限制；少量几个平台重大的硬件限制，多平台系统23需求稳定性对定义好的需求基本不会发生变化基本需求可能会发生一些变化没有基本需求，或基本需求变化很快24需求的完备性和清晰度所有需求都被定义完全且记录清晰某些需求未完成或尚不清楚有某些需求只有客户自己知道25客户期望值客户期望值与项目组相同双方没有正式讨论过项目的期望值，但看起来是相同的客户的期望值与项目组不同26项目完成的标

34、准双方完成的标准是一致的完成标准没有正式讨论过项目组和客户之间在完成项目的标准上有争议27成本/收益计算成本/收益计算已经精确可靠地完成成本/收益计算完成，遗留一些适用性问题对系统的成本/收益没有满意的计算，预算与项目计划脱节28可测试性项目需求很容易被测试，测试计划正在进行中项目的某些部分很难被测试，或测试计划刚刚开始制定了一小部分项目的大部分都难于测试，或项目测试计划尚未开始制定29项目是否适合企业架构项目的实施与企业架构的所有部分都很符合企业架构的某些部分未定义，或与项目的要求有差别企业架构尚未建立，或该架构与项目实施的要求冲突30设计难度项目的设计良好，有完备的接口，且设计文档易于理解

35、设计方法还不很清楚，或某些方面有待于决定接口混乱，难于控制，目标还在变化31实现难度（复杂度）算法和设计合理，易于实现算法和设计的某些方面对项目组有一些难度项目组发现算法和设计中包含有很难实现的组件32系统关联性系统的软件部分和系统其他部分（如硬件、处理流程、文档）的依赖关系的说明很清晰系统的某些部分计划很好，易于理解，但其他部分则难于理解关于整个系统的整合，没有清晰的计划或进度表33可重用组件组件已经可用，且与处理流程兼容组件应该可用，但发布日期未定组件在项目计划中，但需要时却不可用34替代组件组件可以被直接使用组件在绝大多数环境下可用组件在一定的条件下会失败，或组件的发布会推迟，或组件与某

36、些处理流程不兼容项目的决定35行政因素的影响所有决定都不是由行政影响而作出的项目中的某些决定不是因为技术或管理的原因，而是行政上的需要项目中的大多数决定都是行政上的原因，而没有技术或管理上的因素36确定项目结束日期发布日期是基于项目组对项目进展的估计作出的发布时间的确定部分由于市场的需要或其他方面的因素发布日期的确定完全是由于市场的需要，或财务目标，或其他类似因素，却没有考虑到项目组对工作时间的估计37开发技术的选择技术选择完全符合客户的需求之所以选择某种新技术，部分是由于新技术本身项目成了引进新技术的借口，而新的技术对满足用户需求毫无用处38短期的解决方案项目可以满足短期的需求，又不影响长期

37、的规划项目的解决方案只注重于解决目前的问题，而对长期的需求考虑较少解决方案完全是为了能够完成短期的任务，而全然不顾项目的远景规划项目的开发过程39项目的依赖性所有的依赖因素都是已知的，并且有可靠的保证某些依赖条件可能会部分导致延期影响项目的条件是员工、决策或组件不足135评估流程有良好而规范的流程来评估工作量、费用和工作成绩评估的过程是不正式的，但结果代表了大多数人的意见根本不做评估，或评估基于个人的、非正式的推测40对评估结果的信任度任务划分明确，项目组对评估结果高度信任项目组成员对评估结果的某些部分缺乏信任任务划分不明，评估涉及的范围太广，或项目组不信任评估结果41可选方案的分析对可选方案

38、的考虑完全而彻底，假设条件正确对可选方案的分析彻底，但假设条件有问题；或不是所有可能方案都被考虑到分析不完全，某些方案没有被考虑；或假设条件错误42现有系统的文档现有系统的文档完全，格式通用统一，项目组很容易理解且从中获益部分系统有文档说明；每一部分文档有自己的编写方法没有有关现有系统的文档；或现有文档不正确或已过期43改变决议的流程有关目标、内容和时间进度表的改变由所有人讨论并通过决议的改变与所有人交流过没有经过所有人的讨论就改变决议的内容44保证各种流程的实施处理各种事件的流程是适当而有效的，并被项目组严格遵守，从而使得项目能够顺利实施项目组有处理各种事件的流程，但没有被严格遵守没有可以保

39、证项目顺利进行的流程可供遵守46项目文档文档正确可用，由项目组成员在项目进展过程中编写缺少部分文档，但已有文档是可用的，可能滞后于项目进展没有项目文档；没有建立项目内部文档的计划47开发流程的制订和使用项目进展流程已经建立，并且是适当的和高效的，项目组成员遵照该流程工作流程已建立，但效果不好，没有被很好的遵守没有正式的工作流程48及早发现缺陷开发组成员一直坚持对项目的各个部分作检查开发组偶尔对项目作检查开发组希望由测试人员去发现所有的错误49缺陷跟踪缺陷跟踪的方法明确且有效，并一直使用规定了缺陷跟踪的方法，但没有坚持使用没有规定缺陷跟踪的方法50更新控制有有效的正式的更新控制流程，且一直被遵守

40、存在更新控制流程，但效果不好或未被遵守没有使用任何更新控制流程项目开发和部署的环境52物理设备几乎不需要改变某些已存在，其他需要改变需要较大的改造53硬件平台平台稳定，有足够的能力，不需要改变平台有一些变化，但在控制之下平台与软件在开发中54工具可用性有效的，合适的，有文档可用的，有效的，但需要一些二次开发或几乎没有文档没有用处；或有版权问题；或需要大量的二次开发；没有任何文档55其他开发商的支持在需要的时候有完全的支持，且价格合理在合理的响应时间内有足够的支持，且价格已经签约几乎没有支持，价格太高，响应时间长56灾难恢复所有领域都遵守安全准则；数据备份工作完好；有合适的灾难恢复系统；所有工作

41、都遵循以上准则有一些安全措施；有备份数据；灾难恢复已被考虑，但缺乏有效的手段或这些措施没有被完全遵守没有合适的安全措施；缺少备份机制；没有考虑灾难恢复项目（程序）管理57管理方法具有有效的计划和监督的机制和工具计划和监督机制需要加强几乎没有计划和监督机制58管理经验项目经理和程序经理在类似项目上很有经验项目经理和程序经理在类似项目上有一些经验，或在其它项目上有管理经验项目经理和程序经理没有经历过类似项目的管理工作，或在项目管理上是新手59项目和程序经理的权威具有管理上的或官方的权威，可以有效的承担领导项目组的任务基于私人的关系，可以影响组织中的其他成员既没有官方的地位也没有个人的影响，从而在做

42、出决定和资源调配上没有影响力60来自项目组的支持受到项目组和管理层的完全支持项目组中有些人持保留态度，但大多数人表示支持几乎得不到支持，只有名义上的管理权61确定项目标准对于项目的开发，实施和维护，在项目计划中都有标准的程序、方法和工具项目计划中确定了一部分标准的程序、方法和工具项目计划中没有涉及到项目需要使用的程序、方法和工具62交付系统所需的硬件资源系统足够成熟和灵活，且有可扩展的能力硬件系统可用，有一些扩展能力没有扩展能力，不灵活63响应能力和其他性能上的要素已经准备好适应各种情况，已经做过很好的分析偶尔需要应付极端情况在实际操作中总是在满负荷运转79对用户支持服务的影响几乎不需要改变用

43、户支持服务用户支持服务需要很少量的变化需要对用户支持服务作较大的变化；或需要该部门提供更多的支持80数据迁移的需求几乎不需要数据迁移需要大量的数据迁移，但对该过程有清晰的描述，且有明确的迁移方案大量的数据需要迁移，有些数据库系统的迁移没有清晰的描述和详细的文档81外部的软硬件接口几乎不需要与外部的接口集成，或不需要向外界提供接口需要作一些集成或接口工作需要作大量的接口工作136跟踪项目的成绩和成本已经对项目的成绩和成本进行了有效的跟踪，并在他们超出计划范围时作出了有效的努力已经对项目的成本进行了正式的跟踪，并通常在需要时会有正确的动作没有对项目的成本进行跟踪，除非是发现了很大的偏差项目组61项

44、目组成员的可用性总是就绪，几乎没有什么原因可以导致中断工作基本可用，有时候会因紧急事件而中断工作几乎不可用，成员花费大量的时间用于应付紧急事件62综合技能综合技能极好某些技能不是很充分不具备某些必要的技能63项目组是否覆盖了MSF的所有角色所有角色都具备客户需要扮演其中的几个角色关键性的角色缺乏64类似项目的经验项目组在类似项目上有大量的经验在类似项目中有一定经验几乎没有类似项目的经验66开发流程的经验在这种流程上有大量的经验在这种流程上有一些经验或在其他流程上有大量的经验没有正规流程的经验67项目状态的交流项目组成员之间以及项目组与组外人员之间在项目目标和状态上有良好的交流项目组有时候在某些

45、信息上有交流项目组几乎不同那些需要明了项目状态的人员进行交流68m项目组的培训有合适的培训计划，且计划在执行中某些领域没有培训，或计划在将来培训没有任何培训计划，或培训工作尚未准备好69项目组成员的精神状态对项目的成功有强烈的愿望，合作精神好愿意做好自己的工作没有一个凝聚力好的项目组，成员没有做好项目的愿望70项目组的工作效率工作效率很高，达到了所有的里程碑，按时完成所有工作工作效率较好，某些工作有延时，达到了里程碑的要求工作效率低，工作延时，没有达到里程碑的要求71项目领域的专业技术开发组成员在项目涉及的领域有很好的背景知识在该领域有一些专业知识，或在需要时有专家的支持项目组成员在该领域没有

46、专业支持，且没有专家的支持项目技术73技术与项目的符合程度对客户的问题，项目所采用的技术有可靠的解决方案项目计划中采用的技术对解决客户的问题在某些方面不是很合适所选择的技术与解决客户的问题之间有较大的差异74与工业标准的符合程度技术路线符合客户的组织体系和技术架构技术路线对用户是全新的，但是与现存的标准和技术架构没有冲突技术路线与现有的标准或技术架构有矛盾，或没有成文的标准75技术专家的可用性有可用的技术专家在机构中有可用的专家，但不在项目组之内需要在机构外寻找帮助76技术成熟性该技术已经使用了很长时间技术被项目组充分理解采用的是可能导致失败的新技术项目维护82设计复杂性高可维护性某些方面难于

47、维护非常难于维护83维护人员有足够的合适的有经验的人员缺少某些方面的专家非常缺乏受过训练的专家84其他开发商的支持在需要的时候有完全的支持，且价格合理在合理的响应时间内有足够的支持，且价格已经签约几乎没有支持，价格太高，响应时间长85对发行版本的支持客户或合作伙伴被完全包含在项目中，他们承担起完全的支持发行版本的责任客户或合作伙伴愿意承担支持发行版本的责任，但缺乏足够的能力不愿意承担责任，或不认为该工作很重要1.6 变更管理1.6.1 实施范围控制保持项目实施范围的前后一贯性是非常重要的。如果出现需要改变原定实施范围的需求，都应以正式文档方式提出。项目小组成员必须谨慎考虑项目范围的改变将对整个

48、项目进程可能产生的影响，必须在批准后才能进行。在实施过程中必须加以跟踪1.6.2 范围改变文档内容说明范围改变内容、理由。说明改变部分在项目进程中的状态。评估改变部分对项目进程可能的影响。评估改变部分对项目费用可能的影响。1.6.3 批准程序提出实施范围改变请求报告。提交客户方项目经理查阅和签字批准并内部存档， 同时提交项目管理委员会、实施方项目经理等。凡涉及到整个项目进展，费用成本调整较大的改变，必须交由项目管理委员会批准通过。1.6.4 跟踪执行范围改变书签字后，开始正式执行。调整相应的实施计划。任务完成进度报告应当定期提交项目双方检查，完成后应当由双方项目经理签字。1.7 验收方法1.7

49、.1 验收程序项目期间内，在规定进度里程碑，XX公司将交付完成的项目可交付服务，供审查、批准。可交付服务验收程序如下所述。1) 提交可交付服务XX公司项目经理或其指定人，将准备一份可交付服务验收表，并将该表随同有关可交付服务交付给客户的项目经理或客户的指定人员供其考虑。2) 评估可交付服务客户代表将确定可交付服务是否满足本工作说明规定的要求，以及可交付服务是否是完整的。客户要求对经验收的可交付服务进行的额外工作或变更，将通过变更管理程序进行管理。3) 验收/拒收审查后，客户将在2个工作日内（通过签署验收表并署明日期）接收可交付服务，或将提供书面理由，拒收可交付服务，并将验收表退还给XX公司小组

50、。4) 可交付服务的补正可交付服务发现范围内问题的，XX公司将予以补正，并将按照变更管理程序，处理范围外变更的补正事宜。XX公司将在收到被拒收的可交付服务验收表后两2个工作日内，提交变更工作时间表。5) 监督和报告XX公司项目组将对可交付服务验收进行跟踪。可交付服务验收方面的最新消息将纳入每周状况报告，并将在每周状况会议上讨论。不能解决的可交付服务验收问题，将提交项目委员会处理。对可交付服务应在其提交验收后起连续2个工作日内进行审查。在规定的前述时限内未审查或未收到验收回复的，可交付服务视为已获验收。对任何可交付服务的使用或部分使用，构成对该可交付服务的验收。审查期之后提供的回馈，将被作为对范

51、围的潜在变更而予以评估。1.7.2 系统考核期的确定系统试运行1个月后，进行系统最终验收，系统最终验收是为了确认XX公司所提供的系统功能。验收必须是XX公司在场的情况下进行。验收是根据XX公司提供的并经过客户确认的验收方案进行。对于方案中没有提到的情况及方法，由客户与XX公司双方协商决定。在试运行期间XX公司可对系统进行维护，以保证系统考核的合格。系统试运行期间，XX公司可根据运行情况提出考核要求，客户应在XX公司提出要求后两周内开始考核，考核期为一个月。在考核条件具备时，开始考核时间不应迟于XX公司提出考核要求后的三个月，否则视为考核通过。考核是根据XX公司提供的并经过客户确认的考核方案进行

52、。对于方案中没有提到的情况及方法，由客户与XX公司双方协商决定。服务器、工作站、网络等硬件和平台软件不属考核范围。1.7.3 系统功能验收标准考核办法：系统功能测试、实际运行考核。考核标准：功能满足设计方案的规定。项目交付验收的标准为：1) 项目各功能模块，达到双方确认的“技术方案书“中描述的功能要求2) 项目各功能模块，系统功能运行正常。3) 项目各功能模块相关交付文档全部交付。2 项目培训2.1 项目培训策略培训主要分为应用系统操作培训、应用系统管理培训、服务器管理培训，这三种培训在培训内容和培训要求方面是有很大差异的，因此，在整个培训过程中，针对不同的培训内容我们所关注的培训重点也是不一

53、样的。应用系统操作培训应用系统管理培训服务器管理培训系统管理员信息发布人员办公室人员注：重点培训参与培训不参与培训下表显示了项目中进行培训的层次和内容：培训对象培训内容备注系统管理员1 SharePoint 2010管理员培训2 BizTalk 2009 管理员培训3 SQL Server 2008 R2管理员培训4 Windows Server 2008 R2 管理员培训5 企业门户系统管理员培训主要目的是让相关管理人员可以对应用系统和服务器进行日常的配置和管理。信息发布人员1系统操作与使用；2功能介绍；3信息发布操作流程主要目的是为了信息发布人员熟练掌握系统发布操作办公室人员1系统规范介绍

54、；2功能介绍；3 岗位管理规范4 程序操作流程；主要目的是为了办公室人员熟练掌握系统操作培训时间：详细的培训时间安排请参见实施计划。2.2 项目培训方式培训的类别包括：l 应用系统操作培训l 应用系统管理培训l 服务器管理培训其中服务器管理培训采用到XX公司培训教室集中授课形式，而应用系统的操作和管理培训则采取到现场集中培训形式。同时，在项目的实施过程中，我们将根据企业用户的掌握情况有目的地进行个别操作指导。下面根据不同的培训类别说明其培训的具体方式。1）应用系统操作培训：l 培训对象为：系统管理员、信息发布人员、办公室人员。2）应用系统管理培训：l 培训对象为：系统管理员；3）服务器管理培训

55、：l 培训对象为：系统管理员；2.3 培训组织与要求项目过程中的各种系列培训是实施工作的重要内容之一。培训的效果与质量直接影响到财务系统的正常使用与管理。为确保达到培训的目标，XX公司为X客户门户项目制定了完善的项目培训组织与要求，通过培训可以为X客户门户项目的顺利实施打好坚实的基础。培训组织与要求：l 项目双方各指定专人负责培训的全面组织工作。l XX公司项目经理负责安排培训教师，教师提前准备好讲义和教材，建好培训环境，准备考试试题。l 培训期间所有学员须严格按照培训计划的安排参加培训，如对培训工作有任何疑问，须向负责人反映，由双方负责人协调解决各种问题。l 培训负责人有责任维护好课堂正常秩序，严格课堂纪律，做好培训出勤记录。l 所有学员必须按时完成教师布置的各项作业，例如上机操作。l 培训结束后企业与XX公司将对本次培训进行集中总结。