软件开发责任分配矩阵（软件开发划分的各阶段任务尽可能）

本篇文章给大家谈谈软件开发责任分配矩阵，以及软件开发划分的各阶段任务尽可能对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、【PMBOK】你必须知道的数据表现技术
• 2、#PMBOK第六版# 易混淆概念-辨析
• 3、软考系统集成项目管理工程师考什么？
• 4、责任分配矩阵的构成
• 5、RASCI责任矩阵
• 6、project中怎么增加责任分配矩阵

【PMBOK】你必须知道的数据表现技术

在PMBOK知识体系中，工具与技术是很重要的考点，同时也是适用于工作和生活的直接技能和方法。深刻理解工具与技术可以提高自己处理问题的能力。

备考的同学们建议完整看完工具在不同过程中的应用， 提别注意关键字，用于在做题时快速定位某个工具。 仅自我提升的同事们只需要迹老陵看 定义或加粗过程的介绍 就可以了。

收集需求阶段 用来对大量创意 进行分组 的技术，以便进一步审查和分析。

管理质量过程 亲和图可以对潜在缺陷成因 进行分类 ，展示最应关注的领域。

管理质量过程 因果图，又称“鱼骨图”、“why-why分析图”和“石川图”，将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因。图 8-9 是因果图的一个例子。

控制质量过程 因果图用于识别质量含数缺陷和错误可能造成的结果。

控制质量过程 控制图用于确定一个过程是否稳定，或者是否具有可预测的绩效。

规格上限和下限（USL/LSL） ----反映了可允许的最大值和最小值。超出规格界限就可能受处罚（次品）。 控制上限和下限（UCL/LCL） ----代表一个稳定的过程的自然波动范围（失控—无需停产但必须查原因）。控制界限通常设在离过程均值（0西格玛）±3西格玛旳位置。

项目经理和相关方可基于计算出的控制界限，识别须采取纠正措施的检查点，以预防不在控制界限内的绩效。

控制图可用于监测各种类型的输出变量。虽然控制图最常用来跟踪批量生产中的重复性活动，但也可用来监测成本与进度偏差、产量、范围变更频率或其他管理工作成果，以便帮助确定项目管理过程是否受控。

控制图----用来确定一个 过程是否稳定 ，或者 是否具有可预测的绩效 。（无界限的控制图叫“趋势图”）

也称过程图，用来显示在一个或多个输入转化成一个或多个输出的过程中所需要的步骤顺序和可能分支。

它通过映射水平价值链的过程细节来显示活动、决策点、分支循环、并行路径及整体处理顺序。图 8-6 展示了其中一个版本的价值链，即 SIPOC（供应商、输入、过程、输出和客户）模型。

规划质量管理 流程图可能有助于了解和估算一个过程的质量成本。通过工作流的逻辑分支及其相对频率来估算质量成本。这些逻辑分支细分为完成符合要求的输出而需要开展的一致性工作和非一致性工作。用于展示过程步骤时，流程图有时又被称为“过程流程图”或“过程流向图”，可帮助改进过程并识别可能出现质量缺陷姿戚或可以纳入质量检查的地方。

管理质量过程 流程图展示了引发缺陷的一系列步骤。

实施定性风险分析 如果使用了 两个以上的参数 对风险进行分类，那就不能使用概率和影响矩阵，而需要使用其他图形。

例如，气泡图能显示三维数据。在气泡图中，把每个风险都绘制成一个气泡，并用x  轴值、y 轴值和气泡大小来表示风险的三个参数。图 11-10 是气泡图的示例，其中，X轴代表可监测性，Y轴代表邻近性，影响值则以气泡大小表示。

管理质量过程 直方图是一种 展示数字数据的条形图 ，可以展示每个可交付成果的缺陷数量、缺陷成因的排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式。

控制质量过程 直方图可按来源或组成部分展示缺陷数量。

逻辑数据模型把 组织数据可视化 ，以商业语言加以描述， 不依赖 任何特定 软件开发技术 。

规划质量管理  逻辑数据模型可用于 识别 会出现 数据完整性 或其他 质量问题 的地方。

矩阵图在行列交叉的位置展示因素、原因和目标之间的 关系 强弱。根据可用来比较因素的数量，项目经理可使用不同形状的矩阵图，如L 型、T 型、Y 型、X 型、C型和屋顶型矩阵。

规划质量管理 它们有助于识别对项目成功至关重要的质量测量指标。

管理质量过程 矩阵图在行列交叉的位置展示因素、原因和目标之间的 关系强弱 。

规划资源管理过程 适用于本过程的数据表现技术包括（但不限于）图表。数据表现有多种格式来记录和阐明团队成员的角色与职责。大多数格式属于层级型、矩阵型或文本型。有些项目人员安排可以在子计划（如风险、质量或沟通管理计划）中列出。

无论使用什么方法来记录团队成员的角色，目的都是要确保每个工作包都有明确的责任人，确保全体团队成员都清楚地理解其角色和职责。层级型可用于表示高层级角色，而文本型则更适合用于记录详细职责。

1. 层级型。 可以采用传统的组织结构图，自上而下地显示各种职位及其相互关系。

1.1 工作分解结构 (WBS)。 WBS 用来显示如何把项目可交付成果分解为工作包，有助于明确高层级的职责。

1.2 组织分解结构(OBS)。 WBS 显示项目可交付成果的分解，而OBS 则按照组织现有的部门、单元或团队排列，并在每个部门下列出项目活动或工作包。运营部门（如信息技术部或采购部）只需要找到其所在的OBS 位置，就能看到自己的全部项目职责。

1.3 资源分解结构。 资源分解结构是按资源类别和类型，对团队和实物资源的层级列表，用于规划、管理和控制项目工作。每向下一个层次都代表对资源的更详细描述，直到信息细到可以与工作分解结构（WBS）相结合，用来规划和监控项目工作。

2 责任分配矩阵。 责任分配矩阵展示项目资源在各个工作包中的任务分配。矩阵型图表的一个例子是 职责分配矩阵(RAM) ，它显示了分配给每个工作包的项目资源，用于说明工作包或活动与项目团队成员之间的关系。

在大型项目中，可以制定多个层次的RAM。例如，高层次的RAM 可定义项目团队、小组或部门负责WBS 中的哪部分工作，而低层次的 RAM 则可在各小组内为具体活动分配角色、职责和职权。矩阵图能反映与每个人相关的所有活动，以及与每项活动相关的所有人员，它也可确保任何一项任务都只有一个人负责，从而避免职权不清。

RAM的一个例子是 RACI（执行、负责、咨询和知情） 矩阵，如图9-4所示。图中最左边的一列表示有待完成的工作（活动）。分配给每项工作的资源可以是个人或小组，项目经理也可根据项目需要，选择“领导”或“资源”等适用词汇，来分配项目责任。如果团队是由内部和外部人员组成，RACI矩阵对明确划分角色和职责特别有用。

3 文本型。 如果需要 详细描述 团队成员的职责，就可以采用文本型。文本型文件通常以概述的形式，提供诸如职责、职权、能力和资格等方面的信息。这种文件有多种名称，如职位描述、角色  —  职责  —  职权表，该文件可作为未来项目的模板，特别是在根据当前项目的经验教训对其内容进行更新之后。

收集需求阶段 把从 头脑风暴中获得的创意整合成一张图 ，用以反映创意之间的 共性与差异，激发新创意。

规划质量管理 思维导图是一种用于可视化组织信息的绘图法。质量思维导图通常是基于单个质量概念创建的，是绘制在空白的页面中央的图像，之后再增加以图像、词汇或词条形式表现的想法。思维导图技术可以有助于快速收集项目质量要求、制约因素、依赖关系和联系。

规划相关方参与 思维导图用于对相关方信息、相互关系以及他们与组织的关系进行可视化整理。

实施定性风险分析 概率和影响矩阵是把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。此矩阵对概率和影响进行组合，以便于把单个项目风险划分成不同的优先级组别（见图 11-5）。

基于风险的概率和影响，对 风险进行优先级排序 ，以便未来进一步分析并制定应对措施。采用风险管理计划中规定的风险概率和影响定义，逐一对单个项目风险的发生概率及其对一项或多项项目目标的影响（若发生）进行评估。

然后，基于所得到的概率和影响的组合，使用概率和影响矩阵，来为单个项目风险分配优先级别。组织可针对每个项目目标（如成本、时间和范围）制定单独的概率和影响矩阵，并用它们来评估风险针对每个目标的优先级别。组织还可以用不同的方法为每个风险确定一个总体优先级别。即可综合针对不同目标的评估结果，也可采用最高优先级别（无论针对哪个目标），作为风险的总体优先级别。

管理质量过程 散点图是一种展示 两个变量之间的关系 的图形，它能够展示两支轴的关系，一支轴表示过程、环境或活动的任何要素，另一支轴表示质量缺陷。

控制质量过程 散点图可在一支轴上展示计划的绩效，在另一支轴上展示实际绩效。

规划沟通管理  如图13-6所示，相关方参与度评估矩阵显示了个体相关方 当前和期望参与度之间的差距 。在本过程中，可进一步分析该评估矩阵，以便为填补参与度差距而识别额外的沟通需求（除常规报告以外的）。

监督沟通  它可以提供与沟通活动效果有关的信息。应该检查相关方的期望与当前参与度的变化情况，并对沟通进行必要调整。

规划相关方参与 相关方参与度评估矩阵用于将相关方当前参与水平与期望参与水平进行比较。对相关方参与水平进行分类的方式之一，如图 13-6 所示。相关方参与水平可分为如下：

u n 不了解型。不知道项目及其潜在影响。

u n 抵制型。知道项目及其潜在影响，但抵制项目工作或成果可能引发的任何变更。此类相关方不会支持项目工作或项目成果。

u n 中立型。了解项目，但既不支持，也不反对。

u n 支持型。了解项目及其潜在影响，并且会支持项目工作及其成果。

u n 领导型。了解项目及其潜在影响，而且积极参与以确保项目取得成功。

在图 13-6 中，C 代表每个相关方的当前参与水平，而D 是项目团队评估出来的、为确保项目成功所必不可少的参与水平（期望的）。应根据每个相关方的当前与期望参与水平的差距，开展必要的沟通，有效引导相关方参与项目。弥合当前与期望参与水平的差距是监督相关方参与中的一项基本工作。

监督相关方参与  使用相关方参与度评估矩阵，来跟踪每个相关方参与水平的变化，对相关方参与加以监督。

识别相关方   相关方映射分析和表现是一种利用 不同方法对相关方进行分类 的方法。

对相关方进行分类有助于团队与已识别的项目相关方建立关系。常见的分类方法包括：

权力利益方格、权力影响方格，或作用影响方格。基于相关方的职权级别（权力）、对项目成果的关心程度（利益）、对项目成果的影响能力（影响） ，或改变项目计划或执行的能力，每一种方格都可用于对相关方进行分类。对于小型项目、相关方与项目的关系很简单的项目，或相关方之间的关系很简单的项目，这些分类模型非常实用。

相关方立方体。 这是上述方格模型的改良形式。本立方体把上述方格中的要素组合成三维模型，项目经理和团队可据此分析相关方并引导相关方参与项目。作为一个多维模型，它将相关方视为一个多维实体，更好地加以分析，从而有助于沟通策略的制定。

凸显模型。 通过评估相关方的权力（职权级别或对项目成果的影响能力）、紧迫性（因时间约束或相关方对项目成果有重大利益诉求而导致需立即加以关注）和合法性（参与的适当性），对 相关方进行分类 。在凸显模型中，也可以用邻近性取代合法性，以便考察相关方参与项目工作的程度。这种凸显模型适用于复杂的相关方大型社区，或在相关方社区内部存在复杂的关系网络。

凸显模型可用于确定已识别相关方的 相对重要性 。

影响方向。 可以根据相关方对项目工作或项目团队本身的影响方向，对相关方进行分类。可以把相关方分类为：

u n 向上（执行组织或客户组织、发起人和指导委员会的高级高级管理层）；

u n 向下（临时贡献知识或技能的团队或专家）；

u n 向外（项目团队外的相关方群体及其代表，如供应商、政府部门、公众、最终用户和监管部门）；

u n 横向（项目经理的同级人员，如其他项目经理或中层管理人员，他们与项目经理竞争稀缺项目资源或者合作共享资源或信息）。

优先级排序。 如果项目有大量相关方、相关方社区的成员频繁变化，相关方和项目团队之间或相关方社区内部的关系复杂，可能有必要对相关方进行优先级排序。

PMBOK第六版工具与技术系列【更新中】

#PMBOK第六版# 易混淆概念-辨析

项目集管理 重点关注项目间的依赖关系，通过对彼此间存在内在联系的一系列项目的集中管理，实现项目集收益。

项目组合管理 的目的是通过对其所有组成部分（项目集、项目和其他相关工作但彼此间不一定存在必然联系）的审查，实现项目组合的价值最大化。项目集中的项目，彼此间一定有相互的内在联系；而项目组合中的项目集及项目之间，不一定有这种关系。

项目生命周期 是指项目从启动到收尾所经历的一系列阶段，阶段的名称和数量取决于参与项目的一个或多个组织的管理与控制的需要、项目本身特征及其所在的应用领域。通常来说，阶段与阶段的关系有肢纤樱两种基本类型：一是顺序关系排列，二是交叠关系排列，这种阶段交叠被称为“快速跟进”。项目生命周期可长可短，大型项目可划分为多个项目阶段，而简单的小项目可能只有一个阶段，具体划分要根据不同项目的具体需要来确定。所以，不同的项目具有不同的项目生命周期。项目生命周期也有一个框架性的总体结构，不论项目的大小繁简，都可以分为启动项目、组织与准备、执行项目工作和结束项目。

项目管理生命周期 适用于任何项目，不论是大型的土建项目，还是组织一场晚会，都具有相同的项目管理生命周期。

项目采购管理过程所涉及的各种活动构成了 合同生命周期 。在复杂项目中、可能需要同时或先后管理多个合同或分包合同。在这种情况下，单项合同的生命周期可在项目生命周期中的任何阶段结束。从这个意义上说，只有涉及对外采购的项目才具有合同生命周期，并且合同生命周期在时间范围上，包括在对应的项目生命周期内。也就是，合同生命周期的长度小于或等于项目生命周期，一个项目生命周期内可以包含一个或多个合同生命周期。

产品生命周期 包含通常顺序排列且不相互交叉（注意与项目生命周期的区别）的一系列产品阶段，由组织的制造和控制要求决定，如历丛市场调研、产品研发、量产、运营、维护、退市等。产品生命周期往往包括一个或多个项目生命周期。

项目进度管理计划 是项目管理计划的一部分，或者说是其中一个子计划，是项目时间管理知识领域规划进度管理过程的输出。PMBOK指南（第6版）指出，进度管理计划为编制、监督和控制项目进度建立准则和明确活动。其中包括确定进度计划的编制方法和工具，活动持续时间估算的可接受区间、计量单位、绩效测量规则及报告格式等内容。由此可见，项目进度管理计划中并不包含项目具体进展、里程碑等与项目工作进度密切相关的内容。

项目进度计划 是指利用各种进度计划编制工具，如网络分析法、关键路径法、关键链法、资源平衡及相关项目管理软件等，在考虑资源约束的情况下制定的一份标明各项活动的计划开始和结束时间，确定项目里程碑的文件。被批准的进度计划就是进度基准，用来与实际的进度情况对比，得出项目进度绩效。可见项目进度计划是与具体的项目工作密切相关的，这一点与项目管理计划不同。

与进度管理计划和进度计划相类似，范围管理计划和范围基准、成本管理计划和成本基准、质量管理计划和质量测量指标等也有类似区别。总之， “XX管理计划”通常都不会涉及具体的管理内容，而是强调相关制度、流程、政策、工具的选择与应用。在各种“管理计划”中， 唯一例外的是沟通管理计划，其中详细规定了与项目工作相关的沟通对象、沟通需求、沟通频率、沟通方式等细节内容。

根据各 项目管理过程 之间的整合、相互作用及不同用途，将这些过程归纳为5 类，即 启动、规划、执行、监控和收尾 。项目管理过程组是项目管理自身特性决定的，这5大过程组之间有清晰和确定的相互依赖关系，在每个项目上通常都按相同的顺序进行，与应用的领域或行业无关。为有效完成某些重要的可交付成果，在需要特别控制的位置将项目分界，就形成项目阶段。项目阶段大多是按顺序完成的，但在某些竖搭情况下也是可以重叠的。

将项目人为划分 阶段 ，完全是出于对项目有效管理、规划和监控的目的考虑，所以项目的阶段划分是由具体项目的自身需求、特点决定的，不同的项目有不同的项目阶段。任何一个项目阶段都要有相应的阶段成果，成果的完成并被接受是阶段结束的标志。项目阶段不同于项目管理过程组，每个项目阶段一定程度上可以看做一个“子项目”，因此不论这个项目阶段的名称是什么，具体执行时都要用到项目管理全部5大过程组、49个过程的知识与技能。

阶段与阶段之间通常存在3 种基本关系:

①顺序关系—依次完成，无法压缩进度;

② 交叠关系—可以“快速跟进”以压缩进度，但引入了风险;

③迭代关系—走一步看一步，应用于不明确、不确定或快速变化的环境中，但不利于长期规划。

在多阶段项目中，上述3种关系可能都有出现。

纠正措施、预防措施、缺陷补救和更新都属于变更请求的范畴 。其中纠正措施是指为了使项目工作的未来期望绩效与项目管理计划保持一致，而对项目执行工作下达的书面指令。即在监控活动中，当发现当前绩效已经偏离原计划时，所采取的必要措施。该措施必须是正式的、书面的。预防措施是指通过实施某项活动。以降低项目风险消极后果的发生概率的书面指令。即在监控活动中，对预计将要发生的消极风险所采取的事前应对手段。该措施必须是正式的、书面的。

缺陷补救是指识别项目组成部分的某一缺陷之后所形成的正式文件，用于就如何修补该缺陷或彻底替换该部分而提出的建议。即针对已经出现的缺陷所采取的弥补办法，一般缺陷补救仅用于与质量相关的问题。更新是对正规受控的文件或计划等的变更，以反映修改或增加的意见或内容:即更新主要针对既有的流程、制度、政策、计划等文件的修订，而不是指具体的办法和措施。虽同为变更请求范畴的概念，这是区别于纠正措施、预防措施和缺陷补救最大的不同。

项目启动会和项目开踢会这一组概念在考试中经常出现，主要是由于翻泽的问题，让人感觉难以区分。项目启动会议的英文是 initiating meeting ，是在启动阶段结束时召开的会议。该会议的主要任务是发布项目章程，宣布任命的项目经理，并说明项目经理所拥有的权力。另外，还包括团队成员互相认识，介绍项目目标，主要工作内容。让客户方领导表达信心和推动的决心，调动员工的积极性，让客户方从上到下达成一种共识，为项目团队日后开展相关的工作扫除障碍等。项目启动会议的特点是以单向发布为主，不需要互动的讨论、分析等团队活动，通常时间都比较短。

项目开踢会议的英文是 kick‐off meeting ，是在规划阶段结束时召开的会议。该会议的主要目的包括正式批准综合性项目计划，并在干系人之间达成共识，落实具体项目工作， 为进人项目执行阶段做准备;开踢会议召开前，通常已经确定了项目的组织结构，并已经对团队成员的角色与职责进行定义。此时用于指导项目的项目管理计划已经制定出来，已经有了项目范围说明书、范围基准、各分项管理计划、进度计划、采购计划、风险登记册等文件。因此，在开踢会议中，通常需要对项目的范围、进度、成本、风险应对等事项进行确认，并在干系人之间达成共识。

焦点小组会议和引导式研讨会都是项目范围管理知识领域收集需求过程的工具，其中焦点小组会议是把相关干系人、专家集中在一起，由专业的主持人引导大家就产品、服务或成果的期望和态度进行沟通。

引导式研讨会和焦点小组会议相类似的地方是有主持人把控，但最显著的特征是参加引导式研讨会的人一定是跨职能部门的干系人。这种会议方式由于同时引入了不同职能部门人员参与，因而更容易发现问题，是快速定义跨职能需求和协调干系人差异的重要技术，它比单一的会议能更快地发现和解决矛盾，并且效率更高。引导式研讨会的典型实例是软件行业的联合应用开发(JAD)和制造行业的质量功能展开(QFD )。在敏捷开发中，用户故事(user story)也是引导式研讨会的具体应用。

项目工作说明书(SOW) 是制定项目章程过程的输入，是对项目所需交付的产品、服务或成果的叙述说明。项目工作说明书由项目团队以外的发起人、组织、客户等提供，内容相对简单，是对可交付成果的简要介绍，主要包括项目的业务需求、产品范围的大致描述和项目所在组织的战略计划。

采购工作说明书 是规划采购过程的输出，根据PMBOK指南(第6版)中给出的定义，采购工作说明书依据项目范围基准，为每次采购编制工作说明书(SOW)，对将要包含在相关合同中的那一部分项目范围进行定义。采购工作说明书虽然也叫 SOW，但与内容简略、不严谨的项目工作说明书不同，采购工作说明书必须清晰、完整，详细描述拟采购的产品、服务或成果，以便潜在卖方确定他们是否有能力提供这些产品、服务或成果。

项目范围说明书 是定义范围过程的输出，它详细描述项目的可交付成果，以及为提交可交付成果而必须开展且仅需开展的工作，项目范围说明书的编制是由项目团队完成的，是项目干系人之间就范围所达成的共识，主要包括产品范围描述、验收标准、可交付成果、项目除外责任、项目的制约因素和假设条件。如果有合同，合同的条款通常也属于制约因素。项目范围说明书为评价变更请求，或额外工作是否超出项目边界提供基准。从内容上看，项目范围说明书和项目章程有一定程度的重叠，但它们的详细程度完全不同，项目章程记录的与范围相关的内容以高层级信息、为主，而项目范围说明书则是对项目具体范围的详细描述。

项目工作说明书简略，而采购工作说明书和项目范围说明书详细。前者由项目团队以外的组织、发起人、客户提供，后者由负责采购工作的部门或项目团队共同编制。对它们的区分，要抓住上述特点。

工作包 是项目范围管理知识领域中，创建WBS 过程的输出——工作分解结构的底层单元。在这个分解过程中，被分解的对象是项目的可交付成果，虽然叫“工作分解结构”，但是这里的工作是指经过努力而取得的产品、服务或成果，而不是“努力”本身，所以分解得到的工作包，也是精细化、具体化的可交付成果，是名词。可交付成果的分解通常遵循如下原则: 分解层级一般控制在 5层以内，完成每个工作包的工作时间控制在80小时以内(按每天工作 8 小时计算，即不超过 10 个工作日)。

活动 是指为了完成工作包而必须开展的工作，是对工作包进一步分解的产物，是项目时间管理知识领域中，定义活动过程的输出。WBS中的每一个工作包都要分解成活动、通过这些活动来完成可交付成果，所以分解得到的活动描述都是动词。活动是开展估算、编制进度计划及执行和监控项目工作的基础。

确认范围 关注的是客户对已经完成的可交付成果的接受程度，是在项目监控过程中对可交付成果的外部验收。确认范围就是要检查范围，而项目范围是由WBS全部底层的工作包界定的。既然WBS 是对可交付成果的分解，最底层的工作包都是足够精细的可交付成果，那么确认范围自然也是对这些可交付成果的确认和检查。

控制质量 主要关注的是可交付成果是否正确，是否满足质量要求。从对可交付成果的认可角度来说，控制质量是团队内部的自查、自测，属于内部验收。只有通过了内部验收，接下来才能提请外部客户来验收，即确认范围，这属于外部验收。因此控制质量往往要先于确认范围二另外，从它们不同的输出结果也能体现二者的差异:控制质量的输出是核实的可交付成果(内部，团队自己核实、检查);确认范围的输出是验收的可交付成果(外部，由客户确认)。

强制依赖关系 又叫硬逻辑关系、物理依赖关系，它们往往与一些实际的客观限制有关。例如，先计划、再生产，先建地基、再盖楼，是活动本身的特性决定的，是刚性的。另外，合同中规定的、需要执行的条款，也属于强制依赖关系，不能随意改动。

外部依赖关系 是项目活动和非项目活动之间的依赖关系，涉及外部组织的、项目以外的、项目团队无法控制的约束，如项目活动得以开展的配合条件，政府的法律、法规等。例如，产品测试需要受到实验室准备工作的完成才能得以开始，工程的开工必须要通过政府环境测评，节假日的加班必须提前得到类似工会组织的批准等。

内部依赖关系 是项目活动之间的紧前关系，通常在项目团队的控制之中，如只有机器组装完毕，团队才能对其进行测试。这和外部依赖关系是不一样的，属于内部依赖关系的活动其范围在项目以内、或者说它们都是在项目活动清单中记录的内容。

强制依赖关系是项目活动自身客观规律决定的;外部依赖关系多是项目外部组织、部门人为设定的，项目团队无法改变。虽然与项目相关的合同也是法律文件的一种，必须要遵守，但是合同属于项目内部文件，所以也属于强制依赖关系，而不是外部依赖关系，要注意区别。

类比估算和参数估算都是估算活动的工具与技术，在估算活动时间、估算成本等过程中都有应用。

类比估算 是以过去类似项目的参数值为基础，来估算当前项目或未来项目的同类参数。在真实项目中采用类比估算的方法，实际上经常是把和当前类似的以往项目数据照搬过来，直接应用。这种方式通常在项目早期信息不足的情况下使用。类比估算的优点是耗费时间短、成本低，但估算的结果准确性较差，属于粗略估算，这种估算方法综合利用了历史信息、和专家判断。如果用于参考的项目与当前项目有本质的相似，而且参与估算的人员有足够的专业知识和经验，则这种估算结果也是可靠的:请注意，类比估算和自下而上估算不是同一种工具！

从PMBOK指南(第6版)项目成本管理知识领域估算成本过程中可以清楚地看到，类比估算和自下而上估算同属估算成本过程的工具与技术。自下而上估算是对单个工作包或活动的成本、历时进行最具体、细致的估算，然后把这些细节性数据向上汇总或“滚动”到更高层次。这种估算方法实际上可以使用包括类别、参数、三点等所有恰当的估算技术，其准确性通常取决于单个活动或工作包的规模和复杂程度。参数估算也是参照过去的项目经验，但是与类比估算最大的区别是参数估算一定有成熟的数学模型或公式，通过套用公式，计算得出结果。

参数估算通 常适用于简单重复性的工作(如修路、搬砖、铺设电缆等)，而不适用于脑力劳动、创造性劳动(如咨询服务、新产品开发、设计等)。参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。

资源日历 是站在资源的角度，说明相关人员、设备、物资等什么时间可投入项目，什么时间不可用或休息。资源日历中要列出资源的属性，包括经验和/或技能水平，以及资源的来源等信息。资源日历是估算活动资源过程的输入，组建项目团队过程的输出，实施采购过程的输出。

与资源日历概念类似，还有项目日历和自然日历。项目日历规定了可以开展进度活动的工作日和工作班次，是指开展项目工作的基准日历，不含节假日;自然日历是自然时间标段，包括工作日和节假日。这两种日历仅仅表示时间概念，与项目资源无关。例如，虽然资源在周末可以工作(资源日历定义)，但是项目并不可以在周末来执行(项目日历定义)，那么该项任务就不会在周末被执行;或者，虽然定义了任务可以在周末执行(项目日历定义)，但是资源不可以在周末工作(资源日历定义)，那么这项任务也是不会在周末被执行的。

资源直方图 是站在项目的角度，说明项目工作对具体资源的需求，包括在整个项目期间每单位时间，如每周(或每月)需要某人、某部门或整个项目团队的工作小时数。资源直方图是规划人力资源管理的输出(人力资源管理计划的组成部分)的工具。

责任分配矩阵 显示工作包或活动与项目团队成员之间的联系，说明哪项工作由谁负责， 可确保任何一项任务都只有一个人负责，从而避免混乱。责任分配矩阵的典型应用是RACI(执行、负责、咨询和知情)图，用以具体说明每个人在具体工作中的职责差别。责任分配矩阵是规划人力资源管理过程的工具。

提前量和滞后量都是排列活动顺序及制定进度计划过程的工具与技术。

提前量 是指相对于紧前活动，其紧后活动可以提前开始的时间。例如在设计图纸完全交付前 2 周，开始对已经完 成部分进行审核，这是带 2 周提前量的完成到开始的逻辑关系。这里紧后活动的提前开始，不同于进度压缩技术中的快速跟进，提前量是活动本身允许的，不存在引人风险的问题，而快速跟进是把本应顺序执行的活动进行部分或全部并行，以压缩时间，这有可能造成返工和风险增加。

滞后量 是相对于紧前活动，其紧后活动需要推迟开始的时间。例如在标书提交 1 周后，开始启动评标活动，这是带 1 周滞后量的完成到开始的逻辑关系。在进度网络图中，加入提前量可以在条件允许的情况下提早开始紧后活动;而滞后量是在某些限制条件下，在紧前和紧后活动之间增加一段不需要工作或资源的自然时间。需要注意的是，提前量和滞后量的使用不能代替进度活动的逻辑关系。另外，虽然活动的提前量和滞后量将体现在最终的项目进度计划里，但是在估算活动持续时间的时候，不应包含任何活动的滞后量(例如，某活动持续时间 3 天外加 2 天的滞后量，则该活动历时就是 3 天，不能计算为 5 天)。

总浮动时间 ，也叫总时差，是指整个项目的最后一项活动的最早完成时间与项目要求的完工时间的差值。它受到活动的选择性依赖关系的影响。总浮动时间为正，说明进度计划不但可以满足项目按时完成的要求，而且还可以提前完成。总浮动时间为负，说明项目进度不能满足项目按时完工的要求。需要通过赶工等进度压缩技术才能弥补时间的差距。例如，某项目要求 100 天完成，进度计划规划 105 天才能完成，总浮动时间就是‐5 天。如果进度计划规划 97 天完成，总浮动时间就是+3 天。如果进度计划规划也是 100 天完成，总浮动时间就是 0。关键路径就是总浮动时间为 0 或负数的路径，即关键路径法是一个时间约束性的进度计划规划方法，中间没有喘息的机会。关键路径法不考虑资源的约束。

自由浮动时间 ，也叫自由时差，是指某项活动在不影响其紧后活动最早开始时间的情况下可以延迟的时间量，是指向同一活动的各项活动总浮动时间之间的相对差值。既然自由浮动时间是指向同一活动的各项活动的总浮动时间的相对差值，那么只有两项或更多项活动指向同一活动时才存在自由浮动时间。自由浮动时间总是正值。

赶工 是指投人更多的资源.加快工作进度，进而缩短工期，如加班、增加人员、投入额外的费用。并不是所有工作都可以通过赶工压缩进度，赶工一般只对简单重复的工作有效，如卸货、修路、挖沟等。在一般情况下，赶工有可能导致风险和/或成本增加，但是如果当成本与项目持续时间有直接关联时，如项目工作需一要从组织外部聘请按工作日计薪的技术专家，通过赶工来缩短工作周期，也有可能节省总成本。认为采用赶工的手段就一定导致项目成本增加的说法是片面的、不正确的。

快速跟进 把原来应该串行的工作在一定程度上并行执行，比如样机的设计图纸还没有全部通过审核。就开始零部件的生产。活动之间的选择性依赖关系是实现快速跟进的基础，它可能导致返工和风险的增加。

赶工和快速跟进都属于进度压缩技术。两种方法相同的地方是都不改变项目范围，都是针对关键路径上的活动，都可以缩短项目的进度时间，都可能引入风险。一旦压缩了历时，就要重新检查关键路径，压缩后可能出现新的关键路径。

资源平衡和资源平滑都属于资源优化技术。

资源平衡技术 的核心在于将稀缺资源首先用到关键路径的关键活动，使关键路径上的活动的资源需求得到优先保证:通过资源平衡手段，可以避免资源被过度分配的情况。资源平衡会导致关键路径的改变，所以项目工期也会发生变化，通常是延期。

资源平滑 是对进度模型中的活动进行调整，使项目资源需求不超过预定资源限制。不同于资源平衡，资源平滑不改变关键路径，也不影响完工时间，活动只在其自由浮动时间和总、浮动时间允许的范围内延迟，所以资源平滑技术可能无法完全解决资源紧缺、抢夺及过度分配问题。

制约因素和假设条件存在于项目范围说明书中，制约因素是指已经客观存在且对项目范围、成本、进度、人员选择等方面起限制与约束作用的因素，如客户或执行组织事先确定的预算、强制性日期或强制性里程碑(如果把北京奥运会的开幕式看作一个项目，开幕日期定在 2008 年 8 月 8 日，就是一个时间上的制约因素。如果项目是根据合同实施的，那么合同条款的具体规定通常也是项目执行中的制约因素。假设条件是指当前不能确定的，假定为正确、真实或确定的因素。假设条件存在不确定性，影响项目规划的所有方面，也是风险的重要来源。制约因素和假设条件都会限制项目的灵活性。二者最大的区别在于:制约因素是确定的、客观存在的;而假设条件是当前不能确定的。作为项目范围基准的一部分，制约因素和假设条件是定义活动、估算活动持续时间、制定进度计划、估算成本、制定预算、识别风险和规划采购等多个过程的输入。

偏差分析 是控制范围、控制成本、控制风险等过程的工具与技术，是一种事后审查，把实际项目绩效与计划或预期的绩效相比较，根据偏离程度决定是否采取纠正、预防和改进等措施。

趋势分析 是控制成本和控制风险的工具与技术，是一种事前预测，它通过对项目绩效随时间的变化情况进行分析，根据已有的绩效信息，推断、预测项目绩效的未来发展趋势。偏差分析是用当前的绩效数据判断当前的项目状态，趋势分析是用一段时间内的绩效进展情况推断今后的项目状态，含有预测的成分。假设情景分析是制定进度计划过程和控制进度过程的工具/技术。

假设情景分析 是基于己有的进度计划，考虑各种各样的情景，根据假设情景分析的结果来评估项目进度计划在不利条件下的可行性，以及为克服或减轻意外情况的影响而编制应急和应对计划。

假设情景分析与偏差分析和趋势分析不同，它所分析的内容并不是客观存在的，或已经 发生 的绩效，而是对项目活动中有可能出现的假设情况、预置的问题进行推测，即对“如果情景 X 出现，情况会怎样?”这样的问题进行分析。

项目预算决定了被批准用于项目的资金，这个被批准的预算是考核项目成本绩效的基准。

完工预算(BAC) 是在项目启动前做出的，并没有实际工作绩效可以参考，是通过对 WBS 工作包中活动成本进行估算，然后自下而上地汇总，最终得出整个项目的总成本，加上应急储备后，还需经过管理层批准，就是项目完工预算。

完工估算(EAC) 是在项目已经启动，根据当前实际工作绩效估算的项目完工费用。由于工作进展期间的不确定因素影响，实际成本绩效可能偏离最初的完工预算（BAC），如果偏差过大，原绩效基准就需要用当前的完工估算(EAC)取代，成为新的成本基准，也称为新的 BAC。

完工尚需估算(ETC) 指的是从进行估算的当前时间点到最终项目完工这段时间内的工作全部完成需要多少资金的一个估算值。

工作绩效报告 是对收集的信息、进行组织与归纳，并通过与绩效测量基准的比较，来分析和展示绩效:绩效报告是正式的，主要向外部干系人提交项目过程文档。常用格式包括横道图、S 曲线、直方图和表格等，要有对比、分析和结论，通常还要对未来项目的状况和进展做出预计，并定期提交，如工程项目日/周/月报等。工作绩效报告是实施整体变更控制、管理沟通、管理项目团队、控制风险、控制采购等过程的输入，监控项目工作。

工作绩效信息 是从各控制过程收集并整合分析得到的绩效数据，是监控项目工作过程的输入，是确认范围、控制范围、控制进度、控制成本、控制质量、控制沟通、控制风险、控制采购和控制干系人参与等过程的输出。

工作绩效数据 是在执行项目工作过程中，从每个正在执行的活动中收集到的原始数据。相对于经过组织、归纳的绩效报告，工作绩效数据更像原材料，是没有经过加工的原始信息，可以包括项目活动过程中的各种状态、进展、阶段的情况。工作绩效数据可以内部共享并相互传递，但不适合直接提供给外部干系人:工作绩效数据是指导与管理项目工作过程的输出，也是确认范围、控制进度、控制成本、控制质量、控制沟通、控制风险、控制采购和控制干人参与等过程的输入。

（1）质量审计: 它是实施质量保证的工具，是一种独立的结构化审查，用来确定项目活动是否遵循了组织和项目的政策、过程与程序。质量审计的主要目的是在质量保证过程中识别良好/最佳实践和全部的差距/不足，为采取纠正措施提供借鉴:质量审计可事先安排，也可随机进行;司由内部或外部审计师进行。

（2）风险审计: 它是控制风险过程的工具，主要目的是检查并记录风险应对措施在处理已识别风险及其根源方面的有效性，以及风险管理过程的有效性。风险审计应该由尽可能多的项目干系人参与，可以在日常的项目审查会中进行风险审计，也可单独召开风险审计会议。

更多知识点陆续更新，有需要的同学可以私我领取资料。

软考系统集成项目管理工程师考什么？

软考系统集成项目管理工程师包含两个考试科目：基础知识与应用技术。基础知识在上午考试，应用技术在下午考试。系统集成项目管理工程师各科目考试内容有所不同。

根据软考系统集成项目管理工程师考试大纲，各科目考试范围如下：

考试科目1：系统集成项目管理基础知识

1.信息化知识

1.1 信息化基础

1.1.1 信息与信息化

* 信息的定义、属性和传输模型

* 信息系统的定义和属性

* 信息化的概念

* 信息技术发展及趋势

1.1.2 信息化发展战略

* 信息化体系要素

* 信息激茄哗化的战略目标纳缓

* 信息化的指导思想、基本原则

* 我国信息化发展的主要任务和发展重点

1.2 电子政务和电子商务

1.2.1 电子政务

* 电子政务的概念和内容

* 电子政务建设的指导思想和原则

* 电子政务建设的发展方向和应用重点

1.2.2 电子商务

* 电子商务的定义、作用、体系结构和特点

* 电子商务的类型

* 电子商务发展的支撑保障体系

1.3 企业信息化

1.3.1 企业信息化基础

* 工业和信息化的深度融合

* 企业信息化的内涵和意义

* 我国企业信息化发展的战略要点

1.3.2 企业信息化的实践

* 企业资源规划（ERP）

* 客户关系管理（CRM）

* 供应链管理（SCM）

* 企业应用集成

1.4 商业智能（BI）

1.4.1 商业智能的概念

1.4.2 商业智能的主要功能与层次

1.4.3 商业智能的相关技术和软件

1.5 智慧城市

1.5.1 智慧城市的概念及内涵

1.5.2 智慧城市的参考模型

1.5.3 我国智慧城市建设的指导思想、原则和目标

1.5.4 智慧城市建设的主要内容

2.信息系统服务管理

2.1 信息系统服务业

2.1.1 信息系统服务业的发展

2.1.2 信息系统集成的概念和发展

2.1.3 信息系统工程监理的概念和发展

2.1.4 信息系统运行明行维护的概念和发展

2.2 资质管理

2.2.1 信息系统集成资质管理

2.2.2 信息系统工程监理资质管理

2.3 信息技术服务与管理

2.3.1 信息技术服务的概念

2.3.2 信息技术服务的管理框架

* IT服务管理（ITSM）的概念和主要内容

* ITSS的概念和主要内容

3.信息系统审计

3.1 信息系统审计的意义

3.2 信息系统审计的基本方法

4.信息技术知识

4.1 信息系统建设与开发

4.1.1 信息系统建设的基本概念

* 信息系统建设的总体目标

* 信息系统的生命周期、各阶段目标及其主要工作内容

* 信息系统常用的开发方法

4.1.2 信息系统设计

* 方案设计

* 系统架构

4.1.3 软件工程

* 软件需求分析与定义

* 软件设计、测试与维护

* 软件质量保证及质量评价

* 软件配置管理

* 软件过程管理

* 软件开发工具

* 软件复用

4.1.4 面向对象的系统分析与设计

* 面向对象的基本概念

* 统一建模语言UML与可视化建模

* 面向对象的系统分析

* 面向对象的系统设计

4.1.5 软件架构

* 软件架构的定义

* 软件架构的模式

* 软件架构的分析与评估

4.2 基本信息系统集成技术

4.2.1 应用集成技术

* 数据库与数据仓库技术

* Web Service技术

* J2EE架构

* .NET架构

* 软件引擎技术（流程引擎、Ajax引擎）

* 构件和常用构件标准（COM/DCOM/COM+、CORBA和EJB）

* 软件中间件

4.2.2 计算机网络技术

* 网络技术标准与协议

* Internet技术及应用

* 网络分类

* 网络服务器

* 网络交换技术

* 网络存储技术

* 光网络技术

* 无线网络技术

* 网络接入技术

* 综合布线和机房工程

* 网络规划、设计与实施

* 网络安全

* 网络管理

4.3 新一代信息技术

4.3.1 大数据

* 大数据的概念

* 大数据的关键技术

* 大数据发展应用领域和目标

4.3.2 云计算

* 云计算的概念和服务类型

* 云计算的关键技术

* 发展云计算的指导思想、基本原则和目标

* 发展云计算的主要任务

4.3.3 物联网

* 物联网的概念

* 物联网的发展现状

* 物联网的架构

* 物联网的关键技术

* 物联网的应用

4.3.4 移动互联网

* 移动互联网的概念

* 移动互联网的发展现状

* 移动互联网的关键技术

* 移动互联网的应用

4.3.5 互联网＋

* 互联网＋的内涵

* 互联网＋行动

5.项目管理一般知识

5.1 项目管理的理论基础与体系

5.1.1 项目管理基础

* 项目与项目管理的概念

* 系统集成项目的特点

* 项目干系人

5.1.2 项目管理知识体系的构成

5.1.3 项目管理专业领域的关注点

5.2 项目的组织

5.2.1 组织的体系、文化与风格

5.2.2 组织结构

5.3 项目的生命周期

5.3.1 项目生命周期基础

* 项目生命周期的特征

* 项目阶段的特征

* 项目生命周期与产品生命周期的关系

5.3.2 典型的信息系统项目的生命周期模型

* 瀑布模型

* V模型

* 原型化模型

* 螺旋模型

* 迭代模型

5.4 单个项目的管理过程

5.4.1 项目过程

5.4.2 项目管理过程组

5.4.3 过程的交互

6.立项管理

6.1 立项管理内容

6.1.1 需求分析

* 需求分析的概念

* 需求分析的方法

6.1.2 项目建议书

* 项目建议书的内容

* 项目建议书的编制方法

6.1.3 项目可行性研究报告

* 项目可行性研究报告的内容

* 项目可行性研究报告的编制方法

6.1.4 招投标

* 招投标的主要过程和活动

* 招投标文件的主要内容

6.2 建设方的立项管理

6.2.1 立项申请书（项目建议书）的编写、提交和审批

6.2.2 项目的可行性研究

* 可行性研究的主要内容

* 初步可行性研究和详细可行性研究的方法

* 项目论证评估的过程和方法

* 项目可行性研究报告的编写、提交和获得批准

6.2.3 选择项目承建方

* 招标方式

* 其他方式

6.3 承建方的立项管理

6.3.1 项目识别

6.3.2 项目论证

* 承建方技术能力可行性分析的方法

* 承建方人力及其他资源配置能力可行性分析的方法

* 项目财务可行性分析的过程和方法

* 项目风险分析的方法

* 对可能的其他投标者的相关情况分析

6.3.3 投标

* 组建投标小组

* 投标文件编制方法

* 投标关注要点

6.4 签订合同

6.4.1 招标方与候选供应方谈判的要点

6.4.2 建设方与承建方签订合同的过程和要点

7.项目整体管理

7.1 项目整体管理的含义、作用和过程

7.2 项目启动

7.2.1 项目启动所包括的内容

7.2.2 制定项目章程

* 项目章程的作用和内容

* 项目章程制定的依据

* 项目章程制定所采用的技术和工具

* 项目章程制定的成果

7.2.3 选择项目经理

7.3 编制初步范围说明书

7.4 编制项目管理计划

7.4.1 项目管理计划的含义和作用

7.4.2 项目管理计划的内容

7.4.3 编制项目管理计划

* 编制项目管理计划过程

* 编制项目管理计划过程所采用的技术和工具

* 编制项目管理计划的依据和成果

7.5 项目执行

* 指导和管理项目执行采用的主要技术和工具

* 指导和管理项目执行的依据和成果

* 监控项目工作的工具和技术

* 监控项目工作的依据和成果

7.6 项目整体变更管理

7.6.1 项目变更的基本概念

7.6.2 变更管理的基本原则、组织机构和工作流程简介

7.6.3 变更管理的输入

7.6.4 变更管理所采用的技术和工具

7.6.5 变更管理的输出

7.6.6 变更管理与配置管理之间的关系

7.7 项目收尾管理

7.7.1 项目收尾的内容

* 行政收尾和合同收尾

* 项目验收

* 项目总结

* 项目审计

7.7.2 项目收尾所采用的技术和工具

7.7.3 项目收尾的依据和成果

7.7.4 项目组人员转移

7.7.5 项目后评价

* 信息系统目标评价

* 信息系统过程评价

* 信息系统效益评价

* 信息系统可持续性评价

8.项目范围管理

8.1 项目范围管理的概念

8.1.1 项目范围管理的含义及作用

8.1.2 项目范围管理的主要过程

8.2 收集项目需求并编制范围计划

8.2.1 收集项目需求

8.2.2 编制范围计划过程的输入

8.2.3 编制范围计划过程所用的技术和工具

8.2.4 编制范围计划过程的输出

8.3 范围定义

8.3.1 范围定义

* 范围定义的内容和作用

* 范围定义的输入

* 范围定义的工具和技术

* 范围定义的输出

8.3.2 范围说明书

* 项目论证

* 系统描述

* 项目可交付物的描述

* 项目成功要素的描述

8.3.3 工作分解结构（WBS）

* WBS的作用和意义

* WBS包含的内容

8.3.4 WBS创建工作的输入

8.3.5 创建WBS所采用的方法

8.3.6 WBS创建工作的输出

8.4 项目范围确认

8.4.1 项目范围确认的工作要点

8.4.2 项目范围确认的输入

8.4.3 项目范围确认所采用的方法

8.4.4 项目范围确认的输出

8.5 项目范围控制

8.5.1 项目范围控制涉及的主要内容

8.5.2 项目范围控制与用户需求变更的联系

8.5.3 项目范围控制与项目整体变更管理的联系

8.5.4 项目范围控制的输入

8.5.5 项目范围控制所用的技术和工具

8.5.6 项目范围控制的输出

9.项目进度管理

9.1 项目进度管理相关概念

9.1.1 项目进度管理的含义及作用

9.1.2 项目进度管理的主要活动和过程

9.2 规划进度管理过程

9.2.1 规划项目进度管理的输入

9.2.2 规划项目进度管理的工具与技术

9.2.3 规划项目进度管理的输出

9.3 定义活动

9.3.1 定义活动的输入

9.3.2 定义活动的工具与技术

9.3.3 定义活动的输出

9.4 活动排序

9.4.1 活动排序的输入

9.4.2 活动排序的工具和技术

* 前导图法

* 箭线图法

* 确定依赖关系

* 提前量与滞后量

9.4.3 活动排序的输出

9.5 估算活动资源

9.5.1 估算活动资源的输入

9.5.2 估算活动资源的工具和技术

9.5.3 估算活动资源的输出

9.6 估算活动持续时间

9.6.1 估算活动持续时间的输入

9.6.2 估算活动持续时间的工具与技术

9.6.3 估算活动持续时间的输出

* 猎考网判断

* 类比估算

* 参数估算

* 三点估算

* 群体决策技术

* 储备分析

9.7 制定进度计划

9.7.1 制定进度计划的输入

9.7.2 制定进度计划的工具与技术

* 进度网络分析

* 关键路线法

* 关键链法

* 资源优化技术

* 建模技术

* 提前量和滞后量

* 进度压缩

* 进度计划编制工具

9.7.3 制定进度计划的输出

9.8 控制进度

9.8.1 控制进度的概念、主要活动和步骤

9.8.2 控制进度的输入

9.8.3 控制进度的工具和技术

9.8.4 控制进度的输出

10.项目成本管理

10.1 项目成本和成本管理基础

10.1.1 有关成本的基本概念

* 项目成本概念及其构成

* 成本的类型（可变成本、固定成本、直接成本、间接成本、机会成本、沉没成本）

* 应急储备和管理储备

10.1.2 项目成本管理基础

* 项目成本管理的概念、作用和意义

* 项目成本失控的原因

* 项目成本管理的过程

10.2 制定项目成本管理计划

* 项目成本管理计划制定的输入

* 项目成本管理计划制定的技术和工具

* 项目成本管理计划制定的输出

10.3 项目成本估算

10.3.1 项目成本估算的主要相关因素

10.3.2 项目成本估算的主要步骤

10.3.3 项目成本估算的输入

10.3.4 项目成本估算所采用的技术和工具

* 猎考网判断

* 类比估算

* 自下而上估算

* 三点估算

* 储备分析

* 参数模型法

* 卖方投标分析

* 群体决策技术

10.3.5 项目成本估算的输出

10.4 项目成本预算

10.4.1 项目成本预算及作用

10.4.2 制定项目成本预算的步骤

10.4.3 项目成本预算的输入

10.4.4 项目成本预算的技术和工具

* 成本汇总

* 储备分析

* 猎考网判断

* 参数模型

* 资金限制平衡

10.4.5 项目成本预算的输出

10.5 项目成本控制

10.5.1 项目成本控制的主要内容

10.5.2 项目成本控制的输入

10.5.3 项目成本控制所用的技术和工具

* 挣值分析和挣值管理

* 预测

* 完工尚需绩效指数

* 绩效审查

* 储备分析

10.5.4 项目成本控制的输出

11.项目质量管理

11.1 质量管理基础

11.1.1 质量、项目质量与质量管理等相关概念

11.1.2 质量管理的发展阶段

11.1.3 项目质量管理主要活动和流程

11.1.4 国际质量标准

11.2 规划质量管理

11.2.1 规划质量管理的输入

11.2.2 规划质量管理的工具与技术

* 成本收益分析法

* 质量成本法

* 标杆对照（Benchmarking）

* 实验设计

11.2.3 规划质量管理的输出

11.3 实施质量保证

11.3.1 实施质量保证的输入

11.3.2 实施质量保证的方法与工具

* 质量审计

* 过程分析

11.3.3 实施质量保证的输出

11.4 质量控制

11.4.1 质量控制的输入

11.4.2 质量控制的工具与技术

* 七种基本质量工具（因果图、流程图、核查表、帕累托图、直方图、控制图和散点图）

* 新七种基本质量工具（亲和图、过程决策程序图、关联图、树形图、优先矩阵、活动网络图和矩阵图）

* 统计抽样

* 检查

* 审查已批准的变更请求

11.4.3 质量控制的输出

12.项目人力资源管理

12.1 项目人力资源管理有关概念

12.1.1 动机、权力、责任、绩效和责任分配矩阵

12.1.2 项目人力资源管理的过程

12.2 编制项目人力资源计划

12.2.1 编制项目人力资源计划的输入

12.2.2 编制项目人力资源计划的工具与技术

* 组织结构图和职位描述（层次结构图、矩阵图、文本格式、项目计划的其他部分）

* 人际交往

* 组织理论

* 猎考网判断

* 会议

12.2.3 编制项目人力资源计划的输出

12.3 项目团队组织和建设

12.3.1 组建项目团队

* 人力资源获取

* 组建项目团队的输入

* 组建项目团队的工具和技术（事先分派、谈判、招募、虚拟团队、多维决策分析）

* 组建项目团队的输出

12.3.2 项目团队建设

* 项目团队建设的主要目标

* 成功的项目团队的特点

* 项目团队建设的阶段

* 项目团队建设的输入

* 项目团队建设的形式和方法

* 项目团队建设的输出

12.4 项目团队管理

12.4.1 项目团队管理的含义和内容

12.4.2 项目团队管理的方法

12.4.3 项目团队管理的输入

12.4.4 冲突管理

* 冲突的概念

* 冲突的解决

12.4.5 项目团队管理的输出

13.项目沟通管理和干系人管理

13.1 沟通基础

13.1.1 沟通的定义

13.1.2 沟通的方式

13.1.3 沟通渠道的选择

13.1.4 沟通的基本技能

13.2 制定沟通管理计划

13.2.1 沟通管理计划的主要内容

13.2.2 制定沟通管理计划的输入

13.2.3 制定沟通管理计划的工具

13.2.4 制定沟通管理计划的输出

13.3 管理沟通

13.3.1 管理沟通的输入

13.3.2 管理沟通的工具

13.3.3 管理沟通的输出

13.4 控制沟通

13.4.1 沟通控制的输入

13.4.2 控制沟通的技术和方法

13.4.3 沟通控制的输出

13.5 绩效报告

13.5.1 绩效报告的内容

13.5.2 管理绩效报告的输入

13.5.3 管理绩效报告的技术和工具

13.5.4 管理绩效报告的输出

13.6 项目干系人管理

13.6.1 项目干系人管理所涉及的过程

13.6.2 识别项目干系人

* 识别干系人的输入

* 识别干系人的工具和技术

* 识别干系人的输出

13.6.3 编制项目干系人管理计划

* 编制干系人管理计划的输入

* 编制干系人管理计划的工具与技术

* 编制干系人管理计划的输出

13.6.4 管理干系人参与

* 管理干系人参与的输入

* 管理干系人的工具和技术

* 管理干系人参与的输出

13.6.5 控制干系人参与

* 控制干系人参与的输入

* 控制干系人参与的工具和技术

* 控制干系人参与的输出

14.项目合同管理

14.1 项目合同

14.1.1 合同的概念

* 广义合同与狭义合同

* 信息系统工程合同

14.1.2 合同的法律特征

14.1.3 有效合同原则

14.2 项目合同的分类

14.2.1 按信息系统范围划分

* 总承包合同、单项任务承包合同、分包合同

14.2.2 按项目付款方式划分

* 总价合同、单价合同、成本加酬金合同

14.3 项目合同签订

14.3.1 项目合同的内容

* 当事人各自的权利和义务

* 项目费用及工程款的支付方式

* 项目变更约定

* 违约责任

14.3.2 项目合同谈判与签订

* 谈判的概念与谈判过程

* 项目合同签订的注意事项

14.4 项目合同管理

14.4.1 合同管理及作用

14.4.2 合同管理的主要内容

* 合同的签订管理

* 合同的履行管理

* 合同的变更管理

* 合同的档案管理

14.4.3 合同收尾

* 合同收尾的主要内容

* 采购审计

* 合同收尾的输入和输出

14.5 项目合同索赔处理

14.5.1 索赔的概念和类型

14.5.2 索赔的构成条件和依据

* 合同索赔的构成条件

* 合同索赔的依据

14.5.3 索赔的处理

* 索赔流程

* 索赔审核

* 索赔事件处理的原则

14.5.4 合同违约的管理

* 对建设单位违约的管理

* 对承建单位违约的管理

* 对其他类型违约的管理

15.项目采购管理

15.1 采购管理的相关概念和主要过程

15.2 编制采购计划

15.2.1 编制采购计划的输入

15.2.2 用于采购计划编制工作的技术和方法

* 自制/外购分析

* 猎考网判断

* 市场调研

* 会议

15.2.3 编制采购计划的输出

* 采购计划

* 采购工作说明书

* 采购文件（方案邀请书（RFP）、报价邀请书（RFQ）、询价计划编制过程常用到的其他文件）

* 供方选择标准

* 自制/外购决策

* 变更申请

15.2.4 工作说明书（SOW）

* 工作说明书概念

* 工作说明书内容要点

15.3 实施采购

15.3.1 采购方式

* 招标方式

* 其他采购方式（竞争性谈判、单一来源采购或询价）

15.3.2 实施采购的输入

15.3.3 实施采购的方法和技术

* 投标人会议

* 建议书评价技术

* 独立估算

* 猎考网判断

* 刊登广告

* 分析技术

* 采购谈判

15.3.4 实施采购的输出

15.4 招投标

15.4.1 招标人及其权利和义务

15.4.2 招标代理机构

15.4.3 招标方式

15.4.4 招标程序

15.4.5 投标

15.4.6 开标、评标和中标

15.4.7 供方选择

15.4.8 相关法律责任

15.5 控制采购

15.5.1 控制采购的概念

15.5.2 控制采购的输入

15.5.3 控制采购的工具和技术

15.5.4 控制采购的输出

15.5.5 结束采购

16.信息（文档）与配置管理

16.1 信息系统项目相关信息（文档）及其管理

16.1.1 信息系统项目相关信息（文档）的含义和种类

16.1.2 信息系统项目相关信息（文档）管理的规则和方法

* 文档书写规范

* 图表编号规则

* 文档目录编写标准

* 文档管理制度

16.2 配置管理

16.2.1 配置管理有关概念

* 配置项

* 配置项状态

* 配置项版本号

* 配置项版本管理

* 配置基线

* 配置库

* 配置库权限设置

* 配置控制委员会

* 配置管理员

* 配置管理系统

16.2.2 制定配置管理计划

16.2.3 配置标识

16.2.4 配置控制

* 配置控制概念和主要任务

* 基于配置库的变更控制

16.2.5 配置状态报告

16.2.6 配置审计

16.2.7 发布管理和交付

17.项目变更管理

17.1 项目变更基本概念

17.1.1 项目变更的含义和分类

17.1.2 项目变更产生的原因

17.2 变更管理的基本原则

17.3 变更管理角色职责与工作程序

17.3.1 角色职责

* 变更申请人

* 项目经理

* 变更控制委员会（CCB）

* 变更实施人

* 配置管理员

17.3.2 工作程序

* 提出变更申请

* 变更影响分析

* CCB审查批准

* 实施变更

* 监控变更实施

* 结束变更

17.4 项目变更管理的注意事项

17.4.1 变更管理操作要点

17.4.2 变更管理与其他项目管理要素之间的关系

* 变更管理与整体管理

* 变更管理与配置管理

18.项目风险管理

18.1 风险和项目风险管理基本知识

18.1.1 风险的含义和属性

18.1.2 风险的分类

18.1.3 项目风险管理的含义和主要内容

18.2 规划风险管理

18.2.1 规划风险管理的输入

18.2.2 规划风险管理的工具和技术

18.2.3 规划风险管理的输出

18.3 风险识别

18.3.1 风险识别的参与者和原则

18.3.2 风险识别的输入

18.3.3 风险识别的工具和技术

18.3.4 风险识别的输出

18.4 定性风险分析

18.4.1 定性风险分析的输入

18.4.2 定性风险分析的工具和技术

* 风险概率和影响评估

* 概率和影响矩阵

* 风险数据质量评估

* 风险分类

* 风险紧迫性评估

* 猎考网判断

18.4.3 定性风险分析的输出

18.5 定量风险分析

18.5.1 定量风险分析的输入

18.5.2 定量风险分析的工具和技术

* 数据收集和展示技术

* 定量风险分析和建模技术（敏感性分析、预期货币价值分析、建模和模拟）

* 猎考网判断

18.5.3 定量风险分析的输出

18.6 规划风险应对

18.6.1 规划风险应对的输入

18.6.2 规划风险应对的工具和技术

* 消极风险（威胁）的应对策略（规避、转移、减轻、接受）

* 积极风险（机会）的应对策略

* 应急应对策略

* 猎考网判断

18.6.3 规划风险应对的输出

18.7 监控风险

18.7.1 监控风险的输入

18.7.2 监控风险的工具和技术

* 风险再评估

* 风险审计

* 偏差和趋势分析

* 技术绩效测量

* 储备分析

* 会议

18.7.3 监控风险的输出

19.信息系统安全管理

19.1 信息安全管理

19.1.1 信息安全基本知识

* 信息安全定义

* 信息安全属性

19.1.2 信息安全管理的内容

19.2 信息系统安全

19.2.1 信息系统安全的概念

19.2.2 信息系统安全属性

19.2.3 信息系统安全管理体系

* 信息系统安全管理的内容

* 技术体系

* 管理体系

19.3 物理安全管理

19.3.1 计算机机房与设施安全

19.3.2 技术控制

* 检测监视系统

* 人员进/出机房和操作权限范围控制

19.3.3 环境与人身安全

19.3.4 电磁泄露防护

19.4 人员安全管理

19.4.1 安全组织

19.4.2 岗位安全管理

19.4.3 离岗人员安全管理

19.5 应用系统安全管理

19.5.1 应用系统安全管理实施

19.5.2 应用系统运行中的安全管理

* 系统运行安全审查目标

* 系统运行安全与保密的层次构成

* 系统运行安全检查与记录

* 系统运行管理制度

19.5.3 应用软件维护安全管理

* 应用软件维护活动的类别

* 应用软件维护的安全管理目标

* 应用软件维护的工作项

* 应用软件维护的执行步骤

19.6 信息安全等级保护

19.6.1 信息安全保护等级

19.6.2 计算机网络系统安全保护能力等级

20.知识产权管理

20.1 知识产权概念及其内容

20.2 知识产权管理相关法律法规

20.3 知识产权管理工作的范围和内容

21.法律法规和标准规范

21.1 法律

21.1.1 法律基本概念

21.1.2 有关法律

* 合同法

* 招投标法

* 著作权法

* 政府采购法

21.2 标准和标准化

21.2.1 标准化机构

21.2.2 标准分级

21.2.3 标准类型、代号和名称

21.3 系统集成常用技术标准

21.3.1 基础标准

* 软件工程术语 GB/T 11457-2006

* 信息处理 数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编辑符号及约定 GB 1526-1989

* 信息处理系统 计算机系统配置图符号及约定 GB/T 14085-1993

21.3.2 开发标准

* 信息技术 软件生存周期过程 GB/T 8566-2007

* 软件支持环境 GB/T 15853-1995

* 软件维护指南 GB/T 14079-1993

21.3.3 文档标准

* 软件文档管理指南 GB/T 16680-1996

* 计算机软件产品开发文件编制指南 GB/T 8567-2006

* 计算机软件需求规格说明规范 GB/T 9385-2008

21.3.4 管理标准

* 计算机软件配置管理计划规范 GB/T 12505-1990

* 软件工程 产品质量 GB/T 16260-2006

* 计算机软件质量保证计划规范 GB/T 12504-1990

* 计算机软件可靠性和可维护性管理 GB/T 14394-2008

22.专业英语

22.1 具有工程师所要求的英语阅读水平

22.2 掌握本领域的英语词汇

23.项目管理工程师岗位职业道德规范

考试科目2：系统集成项目管理应用技术

1.项目立项

1.1 项目可行性研究

1.1.1 项目机会研究

1.1.2 可行性研究的内容

1.1.3 可行性研究的步骤

1.1.4 可行性研究的方法

1.1.5 可行性研究报告的编制

1.2 项目评估与论证

1.2.1 项目评估的输入

1.2.2 项目评估的程序和方法

1.2.3 项目评估的内容

1.2.4 成本效益分析

1.2.5 编制项目评估论证报告

1.3 建设方的立项管理

1.4 承建方的立项管理

2.采购管理和合同管理

2.1 采购管理

2.1.1 采购的方式和过程

2.1.2 招标和投标

2.2 合同管理

3.项目启动

3.1 项目启动的过程和技术

3.2 制订项目章程

3.3 选择项目经理

4.管理项目资源

4.1 项目人力资源管理

4.2 项目成本管理

5.项目规划

5.1 制定项目的进度管理计划

5.2 制定项目的质量管理计划

5.3 制定项目的风险管理计划

5.4 制定项目的管理计划

6.项目实施

6.1 执行项目沟通计划

6.2 项目绩效检查与评估

6.3 项目团队建设

6.4 管理项目干系人

6.5 信息（文档）管理与配置管理

6.6 执行采购计划

7.项目控制

7.1 项目监督和控制的工具、技术和方法

7.2 整体变更控制

7.3 范围控制

7.4 进度控制

7.5 成本控制

7.6 质量控制

7.7 风险控制

7.8 技术评审与管理评审

8.项目收尾

8.1 项目验收

8.2 项目总结

8.3 合同收尾

8.4 人员转移

8.5 项目后评价

9.信息系统服务管理

9.1 制定信息系统的服务管理计划

9.2 执行信息系统的服务管理计划

9.3 信息系统的运行维护过程的监控

9.4 信息系统服务管理的持续改进

温馨提示：因考试政策、内容不断变化与调整，猎考网提供的以上信息仅供参考，如有异议，请考生以权威部门公布的内容为准！

下方免费复习资料内容介绍：软考程序员历年真题汇总（2015-2018）

格式：ZIP大小：6311.87KB 2023上半年网络管理员备考知识点集锦

格式：DO大小：4136.5KB

资格考试有疑问、不知道如何总结考点内容、不清楚报考考试当地政策，点击底部咨询猎考网，免费领取复习资料

责任分配矩阵的构成

责任矩阵中纵向为工作单元，横向为组织成员或部门名称罩搭，纵向和横向交叉处表示项目游模组织成员或部门在某个工作单元中的职物磨拿责。

责任分配矩阵是一种矩阵图，矩阵中的符号表示项目工作人员在每个工作单元中的参与角色或责任。采用责任矩阵来确定项目参与方的责任和利益关系。

RASCI责任矩阵

RACI矩阵的中文名字叫责任分配矩阵，顾名思义是管理职责分配的工具。RACI矩阵是非常有效的人力资源管理工具和项目管理工具。

A: Accountable负责批准与布置任务，具有目标导向，负责确定目标、确定目标牵头者（即R），并评价“R”所承担目标的完成者裂情况。

R: Responsible负责牵头完成“A”布置的任务与目标，具有结果导向，对“A”布置的任务与目标的结果负全责。所承担任务与目标与其他部门（或岗位）配合时，负责确定需要的配合部门，确定配合部门的工作内容、工作标准等。“R”负责将其牵头的工作分解给相关的“S”、“首段闭C”与“I”。

S: Support负责配合“R”完成指标的工作，达到既定的目标。对于同一燃雀任务，“R”可指定多个“S”。

C: Consulted负责为各个相关的角色提供咨询服务。

I: Informed信息的接受者，与任务的关系最为间接。

项目阶段分为：需求阶段、开发阶段、测试阶段、发布验收阶段。

project中怎么增加责任分配矩阵

增加步骤如下：

1、打开MicrosoftProject软件，打开你的项目计裤扒划。

2、选择“视图”选项卡，在“视图”选项卡中选择“表格”下拉菜单，然后选择“任务使用情况表格”。

3、在“任务使用情况表格”中，选择“字段”选项卡，在“字段”选项胡哪昌卡中选择“责任分配缓游矩阵”。

4、点击“责任分配矩阵”列中的空白单元格，然后单击下拉箭头，选择一个团队成员或团队名称。

5、在“任务使用情况表格”中，输入每个任务的责任或职责。你可以为每个任务分配一个或多个团队成员。

6、保存你的项目计划。

软件开发责任分配矩阵的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件开发划分的各阶段任务尽可能、软件开发责任分配矩阵的信息别忘了在本站进行查找喔。