案例分析考点精编JS-2（沟通 至 项目组合）

案例分析考点精编JS-2（沟通 至 项目组合）

九、沟通管理：
1、项目干系人包括：项目经理，顾客／客户，执行组织，项目团队成员，项目管理团队，出
资人，有影响的人，项目管理办公室。

2、如何进行项目干系人分析：进行项目干系人识别，分析项目干系人的重要程度，进行项目
干系人的支持度分析，针对不同项目干系人，特别是重要的项目干系人，给出管理项目干系人
的建议，并予以实施。

3、如何改进项目沟通：心使用项目管理信息系统；建立沟通基础设施；使用项目沟通模版；
把握项目沟通基本原则；发展更好的沟通技能；把握人际沟通风格；进行良好的冲突管理。

4、沟通基本原则：沟通内外有别；非正式的沟通有助于关系的融洽；采用对方能接受的沟通
风格；沟通的升级原则；扫除沟通的障碍。

5、可能问题和应对措施的补充：缺乏沟通，合作氛围不够；及时信息分发，加强沟通，让客
户了解项目具体情况；注重沟通技巧，建立融洽的合作气氛；没有对团队成员的沟通需求和沟
通风格进行分析；没有开一个高效的会；沟通方式单一；没有冲突管理；开高效会议的做法；
分析成员的沟通风格，从而采用相应的沟通方式面多种沟通方式；采用一些沟通模板；加强冲
突管理；采用一些沟通模板加强冲突管理；多供应商的沟通；解决冲突，包括干系人对项目期
望之间的冲突、资源冲突等；做好干系人分析，调研各集成商的沟通需求；周期性的沟通；突
发事件的协调；内部管理有问题，监管不力；没有或极少与客户进行直接沟通；现场管理制度
执行不力；总包与分包责任不清；客户获取的信息失真，总包推卸责任；客户自己本身的问题
，包括资金、管理水平等；可能监理工作没到位；发挥总包的牵头和监理的协调作用；对共用
资源可用性进行分析，引入资源日历；建立健全项目管理制度并监管其执行；采用项目管理信
息系统。

6、沟通管理计划应该包括以下内容：
通用术语表。
干系人的沟通需求。 
需要沟通的信息，包括语言、格式、内容、详细程度。
发布信息的原因。
发布信息及告知收悉或做出回应（如适用）的时限和频率。
负责沟通相关伯息的人员。
负责授权保密信息发布的人员。
将要接收信息的个人或小组。
传递信息的技术或方法。 
为沟通活动分配的资源，包括时间和预算。
问题升级程序，用于规定下层员工无法解决问题时的上报时限和上报路径。
随项目进展，对沟通管理计划进行更新与优化的方法。

7、沟通方法：切交互式沟通、推式沟通、拉式沟通。

8、沟通方式分类： 参与讨论方式、征询方式、推销方式（说明）、叙述方式，控制程度由弱
到强。 

9、沟通渠道的总量为：n×(n-1) /2, 其中，n代表干系人的数量。

十、干系人管理：
1、干系人管理计划：
(1)关键干系人的所需参与程度和当前参与程度；
(2)干系人变更的范围和影响；
(3)干系人之间的相互关系和潜在交叉；
(4)项目现阶段的干系人沟通需求；
(5)需要分发给干系人的信息，包括语言、格式、内容、详细程度和发送频率；
(6)分发相关信息的理由，以及可能对干系人参与所产生的影响；
(7)随着项目的进展，更新和优化干系人管理计划的方法；

2、干系人登记册包括：基本信息、评估信息、干系人分类。
(1)基本信息，如干系人的姓名、职位、地点、项目角色、联系方式；
(2)评估信息，如主要需求、主要期望、对项目的潜在影响、与生命周期的哪个阶段最
密切相关；
(3)干系人分类，如关键干系人／非关键干系人、内部／外部、支持者／中立者／反对者等。

3、干系人分析的步骤：识别干系人及其相关信息；分析干系人可能的影响并把他们分类和排
序；评估干系人对不同情况可能做出的反应，以便制定相应策略对他们施加正面影响。

4、干系人分类模型：权利／利益方格、权利／影响方格、影响／作用方格、凸显模型。
权利／利益方格：根据干系人的职权大小和对项目结果的关注（利益）程度进行分类。
权利／影响方格：干系人的职权大小以及主动参与（影响）项目的程度进行分类。
影响／作用方格：干系人主动参与（影响）项目的程度及改变项目计划或者执行的能力进行分
类。
凸显模型：根据干系人的权力（施加自己意愿的能力）、紧迫程度和合法性对干系人进行分类
。

5、权力／利益方格的方法：首先关注B区（重点管理、及时汇报－－项目的客户和项目经理的
主管领导）；A区（令其满意）；C区（随时告知）；D区（监督）。

6、干系人的参与程度分类：不知晓、抵制、中立、支持、领导。

7、干系人管理的过程：识别干系人、编制干系人管理计划、管理干系人参与、控制干系人参
与。

十一、风险管理：

1、主要风险来源：需求风险；技术风险；政策风险，法律法规风险；市场风险；运行风险；
团队风险；关键人员风险；预算风险；范围、成本、质量等其它风险。

2、风险管理计划包括以下内容：方法论；角色和职责；预算；制定时间表；风险分类；风险
概率和影响的定义；概率和影响矩阵；修订的干系人承受力；汇报格式；跟踪。

3、风险应对措施：消极风险或威胁：规避，转移，减轻，接受；积极风险或机会：开拓，提
高，分享，接受。

4、风险管理中存在常见问题：
(1)编制风险管理计划存在问题，未结合本项目的实际情况编制计划，仅参照以前的项目模板
来编制；
(2)编制风险管理计划不应只由项目经理一个人来编制，应由项目团队和相关干系人共同参与
，并经充分沟通和评审后才能发布实施；
(3)缺乏风险识别过程，没有对风险进行全面识别，以做好后续风险管理；
(4)缺乏风险的定性和定量分析过程，没有对风险进行详细分析，风险评估和控制缺少依据；
(5)缺乏风险应对规划，没有提前制定好风险的规划应对措施，出现问题时只按各自理解对风
险进行处理，导致项目问题不断；
(6)没有做好风险控制工作，对风险做再评估和审计及偏差趋势分析等，缺乏有效的风险监控
的工具和技术；
(7)没有对进度风险及关联影响进行充分评估，在应对进度风险方面没有做好相应的准备和安
排，也未预留储备；
(8)没有做好技术绩效测量工作，及时进行评审和绩效对比，及时纠偏；
(9)在项目执行过程中，与客户缺乏沟通，这会产生很多不必要的项目风险和隐患； 
(lO)风险管理计划也没有进行追踪检查和更新，没有及时记录和归档。

十二、采购管理：
1、采购管理计划的步骤：需求确定与采购计划的制订、供应商的搜寻与分析、定价、拟定并
发出定单、定单的跟踪和跟催、验货和收货、开票和支付货款、记录管理。

2、采购管理过程包括：编制采购计划；实施采购；控制采购；结束采购。

3、货物入库的条件：
(1)对采购设备进行检验、验收合格的填写《进库检验记录》；
(2)库存核对采购设备对应项目准确无误；
(3)供应商提供的运货单或到货证明；

4、选择供应商因素：供应商的产品价格、质量、和服务。
供应商考虑的因素有：采购总成本、供应商技术水平、服务支持能力、卖方的资质、质量水
平、既往业绩、应对风险的能力。

5、不合格产品，应采取：(1)退货(2)调换(3)降级该做他用。

6、采购需求通常包括标的物的配置、性能、数量、服务等，其中配置、性能等技术性内容最
为关键。

7、需求的类型。通常有独立需求与从属需求。
独立需求是某一项的需求是与其他项目无关。指那些不确定的、随机性的、企业自身不能控制
的需求。
相关需求也叫非独立需求，指某一项的需求是来自其他项目的需求量的派生。

8、常见的采购文件有方案邀请书、报价邀请书、征求供应商意见书、投标邀请书、招标通知
、洽谈邀请以及承包商初始建议征求书。前期签订的合同也是重要的采购文件。

十三、合同管理：
1、项目合同签订的注意事项：
当事人的法律资格：当事人订立合同，应当具有相应的民事权利能力和民事行为能力。
质量验收标准：质量验收标准是一个关键指标。如果双方的验收标准不一致，就会在系统验收
时产生纠纷。
验收时间：当事人没有约定设备的交付时间或者约定不明确的，可以协议补充，不能达成协议
的，依照合同有关条款或交易习惯确定。若仍不能确定，则供货方可以随时履行，采购方也可
以随时要求履行，但应当给予对方必要的准备时间。
技术支持服务。
损害赔偿：原则上，委托方与被委托方都具有损害赔偿这项权利，但比较多的情况是因为承建
方对于企业实施信息系统的困难估计不足， 结果陷入到期后难以完成项目的尴尬局面。
保密约定：当事人在订立合同过程中知悉的商业秘密，无论合同是否成立，不得泄露或者不正
当地使用。泄露或者不正当地使用该商业秘密给对方造成损失的，应当承担损害赔偿责任。
合同附件：合同生效后，当事人就质量、价款或者报酬、履行地点等内容没有约定或者约定不
明确的可以协议补充：不能达成补充协议的，按照合同有关条款或者交易习惯确定。
法律公证：为避免合同纠纷，保证合同订立的合法性，当事人可以将签订的合同拿到公证机关
进行公证。经过公证的合同，具有法律强制执行效力。

2、合同管理里可能会出现的问题：
合同没订好，没有就具体完成的工作形感明确清晰的条款；
甲方没有对需求及其变更进行统一的组织和管理；
缺乏变更的接收／拒绝准则；
项目下系人及其关系分析不到位，范围定义不全面、不准确；
甲乙双方对项目范围没有达成一致认可或承诺；
缺乏项目全生命周期的范围控制；
缺乏客户／用户参与；
甲方无法进行跨部门协调；
实施范围不清楚、验收标准不清楚画项目沟通有问题；
客户不验收或拖延验收、签字、客户有情绪、不付款；
客户对项目质量信心不足、售后没有承诺等；
缺少违约责任相关条款；?缺少变更处理及索赔相关条款；

面对以上问题我们可以采取以下措施：
合同谈判阶段：
(1)缺的明确的工作说明书或更细化的合同条款；
(2)在合同中明确双方的权利和义务，尤其是关于变更问题；
(3)采取措施，确保合同签约双方对合同的条款理解是一致的；
计划阶段：
(1)编制项目范围说明书；
(2)创建工作的分解结构；
(3)制定项目的范围管理计划；
执行阶段：
(1)在项目执行过程中加强对易分解的各项任务的跟踪和记录；
(2)建立与项目干系人进行沟通的统一渠道；
(3)建立整体变更控制的规程并执行；
(4)加强对项目阶段性成果的平审核确认；

在合同管理中，建设方和承建方通常容易产生一些问题：
(1)合同中缺少必要的项目需求描述及违约责任约定；
(2)合同执行过程中没有做好记录工作；
(3)缺少事先约定的合同变更流程；
(4)为项目制定的原需求文件不够清晰或完整（或范围管理没有做好）；
(5)对人员流动给项目带来的风险，缺乏充分的分析和合理有效的应对措施；
(6)没有充分估计项目变更带来的影响（或变更管理没有做好）；
(7)与承建方的沟通管理没有做好或存在问题；

当项目出现变更后为了使项目继续进行，建设方和承建方应该做：
(1)确定一个变更控制委员会，确定合同变更流程；
(2)对于需求变更带来的影响进行合理的评估，形成新的需求文件；
(3)双方协商对合同内容进行变更，提交CCB批准；
(4)加强沟通，双方各自作出一定的让步（或考虑再延长一定时间的工期，或补偿合理的项目
费用）

3、合同管理的内容：合同签订管理、合同履行管理、合同变更管理、合同档案管理、合同违
约索赔管理。

4、索赔流程：提出索赔要求、报送索赔资料、监理工程师答复、监理工程师逾期答复后果、
持续索赔、仲裁与诉讼。

5、如果甲方向乙方公司提出索赔要求，乙方应该如何处理？
公司在接到甲方的索赔要求及索赔材料后，应根据公司与甲方签订的合同，进行认真分析和 
评估，给出索赔答复；在双方对索赔认可达成一致的基础上，向甲方进行赔付；如双方不能协
商一致， 按照合同约 定进行仲裁或诉讼；同时公司依据与其他相关公司（下游供应商或分包
商）签订的合同，向其他公司提出索赔要求，按索赔流程处理。

6、后续可以怎么做？
对双方的需求（项目范围）做一次全面的沟通和说明，达成一致，并记录下来，请建设方签字
确认。
就完成的工作与建设方沟通确认，并请建设方签字。
就待完成的工作列出清单，以便完成时请建设方确认。
就合同中的验收标准、步骤和方法与建设方协商一致。
必要时可签署一份售后服务承诺书，将此项目周期内无法完成的任务做一个备忘，承诺在后续
的服务期内完成，先保证项目能按时验收。
对于建设方提出的新需求，可与建设方协商进行合同变更，或签订补充合同。

7、合同类型的选择？索赔流程？结合案例会应用

十四、文档和配置管理：
l、配置管理的6个活动：制定配置管理计划；配置标识；配置控制；配置状态报告；＠配置审
计；＠发布管理和交付。

2、配置管理问题：
没有项目管理经验，不适合项目经理的职位；
项目经理兼任配置管理员，精力不够，无法完成配置管理工作；
范围管理有问题；
版本管理没有做好，没有统一的版本管理机制，各版本不可追溯，导致重要版本丢失；
项目中没有建立基线，导致需求、设计、编码无法对应；
没有做好变更管理，项目中的变更不可控；
配置管理计划不应山CCB制定；
基线变更流程缺少变更验证（或确认）环节；
CCB成员的要求不应以人数作为规定，而是以能否代表项目干系人利益为原则；
该公司可能没有版本管理规定或甲乙没有统一执行版本规定；
变更审查应该提交CCB审核；
变更发布应交由CMO完成；
甲乙两人不能同时修改错误；
没有做配置管理规划，缺少完整的配置管理方案；
缺少配置管理及变更管理流程，没有配置管理委员会；
试运行的系统版本没有及时建立基线并让各业务部门正式确认；
配置权限管理存在问题；
人员职责不清晰，没有CMO (配置管理员）的参与并控制配置权限；
开发人员没有按照变更流程的要求修改系统及代码；
开发人员修改代码后没有及时修改文档，导致两者不一致；
代码被修改后没有及时进行回归测试并请干系人确认；
文档管理存在问题，没有做好文档的交接、更新、变更管理工作；
配置管理过程中没有做好相应的记录；
新人的培训工作没有跟进到位。

3、改进措施：
从项目整体出发，做好配置管理规划；
定义合理的配置管理流程，规定项目中出现变更的处理办法；
与各方干系人达成共识，组建配置管理委员会；
识别配置项，并为配置项建立惟一标识，保证其可追溯；
建立配置基线，使重要配置项处于受控状态；
定期提效配置状态报告，改进配置管理方法；
组建配置管理方案设计小组；
仔细了解单位的情况、历史、人员、组织形式等；
对配置管理工具进行有效评估；
制定全面有效的配置管理计划，包括建立配置管理环境、组织机构、成本、进度等，在配置管
理计划中详细描述，建立示例配置库、配置标识管理 配置库控制、配置的检查和评审、配置
库的备份、配置管理计划附属文档；
梳理变更脉络，确定统一的最终需求和设计；
梳理配置项及其历史版本；
对照最终需求和设计逐项分析现有配置项及历史版本的符合情况；
根据分析结果山干系人确定整体变更计划并实施；
加强整体版本管理。

4、配置项：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件
所需的各种数据，它们经评审和检查通过后进入软件配置管理。

5、配置管理中的权限问题：所有配置项的操作权限应由配置管理员(CMO)严格管理，原则是：
基线配置项向软件开发人员开放读取的权限；非基线配置项可以向项目经理(PM)、变更管理委
员会(CCB)及相关人员开放；
基线配置项包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等
。

6、配置识别的内容如下：
识别需要受控的软件配置项。
给每个产品和它的组件及相关的文档分配唯一标识。
定义每个配置项的重要特征及识别其所有者。
识别组件、数据及产品获取点和准则。
建立和控制基线。
维护文件盒组件的修订与产品版本之间的关系。

7、配置库：开发库、受控库、产品库：
(1)动态库。也成为开发库、工作库或程序员库，用于保存开发人员当前正在开发的配置实体
。动态库通常包括新模块、文档、数据元素或进行修改的已有元素。动态库是软件工程师的工
作区，由工程师控制。
(2)受控库。也称为主库或系统库，是用于管理当前基线和控制对基线的变更。受控库包括配
置单元和被提升并集成到配置项中的组件。软件工程师和其他人员可以自由地复制受控库中的
单元或组件。然而，必须有适当的权限授权变更。受控库中的单元或组件用于创建集成、系统
和验收测试或对用户发布的构建。
(3)静态库。也称为软件仓库或软件产品库，用于存档各种广泛使用的已发布的基线。静态库
用于控制、保存和检索主媒介。
(4)备份库。包括制作软件和相关构架、数据和文档的不同版本的复制品。在各点的及时备份
，可以每天、每周或每月执行备份。

8、配置库的建库模式：
决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分
类建库和按任务建库。
(1)按配置项的类型分类建库的方式经常被一些咨询服务公司所推荐，它适用与通用的应用软
件开发组织。这样的组织，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求
。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。
但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作
目录结构过于复杂，带来一些不必要的麻烦。
(2)按照任务建立相应的配置库，则适用于专业软件的研发组织。在这样的组织内，使用的开
发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格地分类存储，人为
增加目录的复杂性。对于研发性的软件组织来说，还是采用这种设置策略比较灵活。

9、配置审计：功能配置审计、物理配置审计。
配置审计的目的：
(1)防止出现向用户提交不适合的产品，如交付了用户手册的不正确版本。
(2)发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更。
(3)找出各配置项间不匹配或不相容的现象。
(4)确认配置项已在所要求的质量控制审查之后作为基线入库保存。
(5)确认记录和文档保持着可追溯性。

10、配置项的状态可分为“草稿 ”、“正式”和“修改” 三种。配置项刚建立时，其状态为
“草稿”。配置项通过评审后其状态变为“正式”。此后若更改配置项，则其状态变为“修改
”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。

11、配置管理中各个成员的职责（3个图，详见课本）
注意受控库中的权限，测试人员、QA在代码权限上没有CHEEK、ADD权限。

十五、变更管理：

1、变更的流程：提出与接受变更申请；对变更的初审；变更方案论证；CCB审查；发出变更通
知并组织实施；变更实施的监控；变更效果评估；判断发生变更后的项目是否已纳入正常轨道
。

2、变更的原因：l、计划、定义有误； 2、项目执行有偏差；3、外部环境的改变；4、客户新
的需要；5、为了应对紧急事件。

3、项目变更有的多种分类方式：
(1)按变更性质分为重大变更、 重要变更和一般变更， 可通过不同审批权限控制。
(2)按变更的迫切性分为紧急变更和非紧急变更，可通过不同的变更处理流程进行控制。
(3)按变更所发生的领域和阶段，可分为进度变更、成本变更、质量变更、设计变更、实施变
更和工作（产品）范围变更等。
(4)按变更来源可分为内部变更和外部变更等。

4、变更管理过程涉及到的角色主要包括项目经理、变更申请人、CCB、变更实施人、配置管理
员。

5、变更问题与措施：
常见问题：未制定标准的变更管理流程；未书面记录变更；未充分评估变更影响；未成立CCB
(CCB未包括客户）；未及时更新项目管理计划及文件；未及时与干系人沟通；未验证和监控变
更；
应对措施：建立规范的变更控制流程；书面申请和记录变更；应充分评估变更影响；应建立
CCB, 包含客户等干系人；及时更新项目计划和文件； 及时与干系人沟通变更影响和结果；变
更后要验证和监控变更；

6、请分析该项目实施过程中存在哪些主要问题。
(1)未提交书面变更申请，项目经理没有按照变更管理的流程要求制定变更规则。
(2)变更控制委员会组成成员不合理，应该包括客户代表，最好是高级管理人员，并明确分工
。
(3)几乎所有变更都被批准和接受，说明CCB没有严格控制项目变更申请的提交，没有认真审核
。
(4)应该对变更因素施加影响，积极沟通，确认变更的必要性。
(5)没有进行变更后的评审，对变更造成的影响没有进行分析。
(6)没有将变更可能造成的影响告诉变更提出方（或对应的干系人）。
(7)没有严格按照变更控制流程进行变更管理。
(8)没有对变更作记录并形成文档，造成变更内容无法追溯。
(9)变更批准后，没有及时更新相应的项目计划和文件，导致内容不一致。
(lO)变更结果没有进行正式验证， 未得到客户的确认
(11)是否接受或拒绝变更，不应该全部山项目经理（或某个人）决定。
(12)项目变更后没有相应的变更合同。
(13)客户需求发生变化时，应该由项目经理进行变更影响评估，而不是由其他人进行。
(14)对于变更请求，任何人不能直接进行修改，应该由 CCB (变更控制委员会）决策，同意修
改后，由项目经理安排相关人员进行修改。
(15)没有对变更影响作评估以及对变更方案的论证。
(16)没有成立CCB (变更控制委员会）。
(17)缺乏对变更过程的监控措施。
(18)没有对变更的效果作评估。
(19)没有变更文件。

7、没有做好变更可能的后果（影响）：
(1)没有遵循正式的变更控制流程，可能导致（范围）需求变更的过程失控和不可追溯。
(2)没有对变更的影响进行完整的分析，可能导致无法全面了解这次变更对项目的进度、范围
、成本、质量等造成多大的影响。
(3)没有修改更新项目管理计划，可能导致实际工作内容与计划有较大的偏差，使项目管 理计
划无法指导项目实施。
(4)没有对相应技术文档进行修改可能导致需求、设计与编码无法对应，不利于后期的测试和
以后的维护工作。
(5)版本管理和配置管理没有做好，可能导致在变更失败后无法将项目恢复到变更前的状态。
(6)没有让用户对最终结果进行确认，可能导致双方对变更结果的意见不一致，不利于项目验
收和最终交付。

8、变更控制委员会(CCB), 也称为配置控制委员会：CCB是决策机构，不是作业机构。通常，
CCB的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。
项目经理(PM)：项目经理对项目负责，其正式权利由项目章程取得，而资源调度的权力通常在
项目基准中明确规定。项目基准中不包括的储备资源需经授权人批准后方可使用。

变更管理包括一下内容：(1)基准管理(2)建立变更控制流程(3)完整体现变更的影响(4)明确组
织分工(5)妥善保存变更产生的相关文档。

有可能的问题：对用户的要求未进行记录；对变更的请求未进行足够的分析，也没有获得批准
；在修改的过程中没有注意进行版本管理；修改完成后未进行验证；修改的内容未和项目干系
人进行沟通。

导致的后果：
缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变
化情况失去把握；缺乏对变更请求的分析可能会导致后期的变更工作失误；在修改过程中不注
意版本管理，一方面可能会导致当变更失败时无法进行复原；另一方面，对于组织财富和经验
的积累也是不利的；修改完成后不进行验证则难以确证变更是否正确实现；未与项目干系人进
行沟通可能会导致项目干系人的工作之间出现不一致之处。

可能案例（变更方面答题要点）：
(1)在项目功能和标准不明确的时候就签订了合同，为后来的项目变更埋下了隐患；
(2)没有建立项目变更管理制度（例如开发人员随口答应，不上报给项目经理）；
(3)作为上点的衍生品，还可以回答，变更请求没有经过评估，没有评估产生的费用和技术要
求，也没有签字确认；
(4)变更实施时没有考虑对系统其他功能的影响，也没有考虑能否实现；
(5)变更后没有进行验证；
(6)没有对变更后的内容进行存档，也没有通知给相关的项目干系人。

十六、收尾管理：

1、项目收尾管理工作包括：心项目验收工作；项目总结工作；系统维护工作；项目后评价工
作。

2、总结的内容应包括：项目绩效、技术绩效、成本绩效、进度计划、绩效识别问题和解决问
题意见和建议。

3、项目总结内容和意义：
了解项目全过程的工作悄况及相关的团队或成员的绩效状况。
了解出现的问题并进行改进措施总结。
了解项目全过程中出现的值得吸取的经验并进行总结。
对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产。

4、验收工作的步骤：l、系统测试；2、系统试运行；3、文档验收；4、最终验收报告。

5、对于系统集成项目，所涉及的文档应该包含如下部分：系统集成项目介绍、系统集成项目
最终报告、信息系统说明手册、信息系统维护手册、软硬件产品说明书、 质量保证书等。

6、怎么才可以促使甲方项目验收？
请求公司的管理层出面去与甲方协调；
重新确认需求并获得各方认可；
和甲方明确合同、以及双方确认的补充协议等，包括修改后的范围、进度和质量方面的文件等
，作为验收标准；
准备好相应的项目结项文档，向甲方提交；

7、可能的收尾的问题？
没有充分做好验收前的准备，或软件系统没有达到验收前的标准，或软件还存在计划修复的缺
陷，这些缺陷未经修复和确认便进入正式验收环节。
在验收过程中未根据变更控制流程对软件进行修改，导致文档与软件不一致。
软件更新后没有对文档进行变更便交付给客户。
项目验收未正式完成，未签署验收报告变更进行了项目总结。
项目收尾过程不完整，缺少正式的项目总结环节，不能只编写总结报告。
项目总结报告未能反映项目的实际情况。
缺少项目评估或审计环节。

8、验收中存在的主要问题：没有进行有效的系统测试；没有准备好相应的文档；没有按照规
范的流程进行验收；与客户的沟通不良。

十七、项目集、 项目组合、 测试管理：

一、测试管理部分:

l、软件测试的方案：
(1)测试目的：发现软件的缺陷，识别问题；
(2)测试对象：软件等相关系统；
(3)测试过程：开始软件测试工作（具有测试合同，具有各种文档，所提交的被测软件已受控
，软件源代码已正确通过编译或汇编），结束软件测试工作；
(4)测试用例设计原则和测试用例要素：每份测试用例包括名称和标识、测试追踪用例说明、
测试的初始化要求、测试的输入、期望的测试结果、评价等等；
(5)测试的类型：单元测试、集成测试、确认测试；
(6)测试的技术和方法：静态剌试、动态测试。具体包括检查、代码走查、代码审查等；

2、当按照测试技术划分时，软件测试类型分为黑盒测试、白盒测试和灰盒测试。
(1)黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用，在完全不考虑
程序内部结构和内部特性的情况下，在程序接口进行测试，只检查程序功能是否按照需求规格
说明书的规定正常使用，主要是针对软件界面和功能进行测试。是以用户的角度，从输入数据
与输出数据的对应关系出发进行测试的。
(2)白盒测试又称为结构测试，需要清楚了解程序结构和处理过程，检查是否所有的结构和路
径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。目的是通过检查软件
内部的逻辑结构，对软件中逻辑路径进行覆盖的测试，可以覆盖全部代码、分支、路径和条件
。
(3)灰盒测试介于白盒测试与黑盒测试之间，是基于程序运行时的外部表现 同时又结合程序内
部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。
在灰盒测试中，无需关心模块内部的实现细节。对于软件系统的内部模块，灰盒测试依然把它
当成一个黑盒来看待。

3、软件的生命周期通常包括：可行性分析与项目开发计划、需求分析、概要设计、详细设计
、编码、测试、维护等阶段。

4、按照开发阶段划分时，软件测试类型分为单元测试、集成测试、系统测试和验收测试。
(1)单元测试：单元测试又称模块测试，是针对软件设计的最小单元进行正确性检验的工作。
程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。
(2)集成测试：集成测试又称组装测试、联合测试、子系统测试或部件测试。集成测试是在单
元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成子系统或系统进行的测试
活动。集成测试关注的是模块间的接口，接口之间的数据传递关系，单元组合后是否实现预计
的功能，其目的是要找出在模块接口上面，包括整体体系结构上的问题。有非增值式策
略（单个—>整体）和增值式策略（单个—>逐步到整体）。
(3)系统测试：是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和 性能
等是否满足其规约所指定的要求。系统测试的对象不仅仅包括需要测试的产品系统的软件，还
要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。系统测试更多
程度上是站在用户的角度上对系统做功能性的验证，同时还对系统进行一些非功能性的验证，
包括压力测试、安全性测试、容错测试、恢复性测试等。
(4)验收测试：是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测
试活动，它是技术测试的最后一个阶段，也称为交付测试、发布测试或确认测试。验收测试是
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定
是否接收系统。验收测试主要包括易用性测试、兼容性测试、安装测试、文档（如用户手册、
操作手册等）测试等几个方面的内容。

5、测试管理的内容按照管理范围和对象，一般可分为测试部门管理和测试项目管理两种。测
试部门管理包含部门日常事务、部门人员、部门下属项目、部门资产等的跟踪及管理工作。测
试项目管理包含测试人员管理、 测试计划及测试策略的编写、测试评审的组织、测试过程的
跟进、测试内部和外部的沟通协调、缺陷跟踪等。

6、测试风险主要包括需求风险、测试用例风险、缺陷风险、代码质量风险、测试环境风险、
测试技术风险、回归测试风险、沟通协调风险和其他不可预计风险。

7、软件测试过程的主要模型有：V模型、W模型、H模型、X模型、前置测试模型。

二、项目集：
l、项目集定义为 “经过协调管理以获取单独管理所无法取得的收益的一组相关联的项目、子
项目集和项目集活动”。项目集内的所有项目通过共同的目标相关联，该目标对发起组织而言
具有非常重要的战略意义。如果项目集各干系人有不同的目标，并且这些目标不具有协调收益
的交付特征，只是在资金、技能、干系人等方面存在关联，则这些最好通过项目组合来管理。

2、项目集经理监控和分析组件之间的相互依赖关系，以协助确定将这些组件作为项目集来管
理的最佳方法。与这些依赖关系相关的行动包括：
(1)领导和协调共同的项目集活动，如跨所有项目集组件、工作或阶段的财务与采购。 解决影
响项目集内多个组件的资源限制和／或冲突问题。
(2)以一种可以体现项目集内所有活动的方式传递并报告给干系人。
(3)积极响应项目集内跨多个组件的风险。
(4)将项目集工作与影响和作用于单独的组件、组件群或项目集目的目标和组织（战略）方向
保持一致。
(5)在共享的治理结构内解决范围、成本、进度、质量和风险影响。
(6)裁剪项目集管理活动、过程和接口，有效地处理项目集内的文化、社会经济、政治和环境
差异。

3、项目集管理与项目管理之间的关键区别是项目集的战略聚焦， 以及项目集确保组织收益的
实现。

4、项目集治理涵盖了山发起组织对项目集战略进行定义、授权、监督和支持的体系和方法，
是项目集发起组织确保项目集被有效和持续管理而执行的实践和流程。

5、项目集治理主要包括以下具体内容：
(1)项目集指导委员会的建立。
(2)项目集指导委员会的职责界定。
(3)项目集治理和项目集管理之间的关系。
(4)与项目集治理相关的个人角色。
(5)项目集作为治理主体—项目集组件治理。 
(6)其他支持项目集管理的治理活动。

6、项目集路线图按照时间顺序以图形化的方式展现项目集预期发展方向，并在每个时间顺
序事件建立系列的文档化标准，同时建立了项目集活动与预期收益之间的关系，以及项目集里
程碑之间的关键依赖，传递业务战略与规划的优先级之间的连接。

7、根据项目集收益的实现情况将项目集生命周期划分为项目集定义阶段、项目集收益交付阶
段和项目集收尾阶段三个过程。

三、项目组合：
l、项目组合是将项目、项目集，以及其他方面的工作内容组合起来进行有效管理，以保证满
足组织的战略性的业务目标。项目组合中的部件不见得要相互依赖或者直接相关。项目组合代
表的组织的投资决策、项目优先级的排序以及资源的分配。

2、项目组合包含项目集、项目、项目组合子集以及日常运作业务， 其目的在于通过组合管
理方式来实现组织的战略目标。 项目集则是项目子集、项目以及日常运作业务的集合， 组通
过项目集管理来支持项目组合管理。

3、项目组合管理活动包括：识别和确定组织的优先活动；确定项目治理和项目绩效管理的管
理框架；衡量项目价值／项目利益；做出投资决策；管理风险、沟通、资源。
项目组合是组织战略意图、战略方向以及战略进展的体现形式。

4、在组织级项目管理中，要求项目组合、项目集与项目与组织的战略方向保持一致；另一方
面，三者为实现战略目标所做出的贡献又各有不同：
项目组合通过选择正确的项目集和项目、设定工作的优先级别并提供必需的资源的方式来促成
组织的战略实现；
项目集管理则是对其所包含的项目子集和项目的依赖没系进行有效管理，从而实现项目集的特
定利益；
项目管理通过制定和实施集合来完成特定的工作范围，支持项目集和项目组合目标的实现，最
终确保组织战略得以实现。

5、项目组合治理管理包括对项目组合进行计划、定义、优化和批准，以及监督项目组合的执
行情况，其目的在于支持组织级别的完整决策。项目组合治理管理主要包如下五个子过程：
(1)制定项目组合管理计划(2)定义项目组合(3)优化项目组合(4)批准项目组合(5)执行项目组
合监督

6、项目组合管理过程组： (1)定义过程组(2)调整过程组(3)授权与控制过程组

7、项目组合风险管理过程主要包含制订项目组合风险管理计划以及管理项目组合风险两个子
过程，如下：
(1)制订项目组合风险管理计划：包括识别项目组合的风险、风险责任人、风险承受能力以及
风险管理过程。
(2)管理项目组合风险：执行项目组合风险管理计划，包括风险评估、风险响应以及监督风险
。