软件项目管理知识点整理
该文主要收录一些关于软件项目管理的文章链接,以及一些知识点整理,不定期添加内容
1.简化功能点系列之一:什么是功能点(Author:火星人陈勇)
【该链接主要介绍什么是项目估算,为什么做项目估算,以及部分项目估算的方法及其优缺点】
【该链接主要介绍功能点估算法】
6.软件项目管理考前复习资料(Author:ZNineSun)
7.软件项目管理期末选择题复习100题(含答案)(Author:bingoCoder)
8.《软件项目管理》课程知识总结(Author:Eastmount)
9.山东大学软件学院软件项目管理复习答案(Author:nfnsl)
10.软件项目管理整理——思维导图(Author:five)
【复习】
前言 软件项目管理概述
1.项目定义:利用有限的资源和时间,为特定用户提供特定产品、服务或成果,而进行的一系列临时性、一次性工作。
2.项目特征:
- 目标性
- 相关性
- 临时性
- 独特性
- 资源约束性
- 不确定性
- 演进性
3.项目管理知识体系(PMBOK)的10个知识领域:
- 项目集成管理
- 项目范围管理
- 项目进度管理
- 项目成本管理
- 项目质量管理
- 项目资源管理
- 项目沟通管理
- 项目风险管理
- 项目采购管理
- 项目干系人管理
4.项目管理知识体系的5个标准化过程组(也称为项目生命周期的5个阶段):启动、计划、执行、控制、收尾。
5.项目与日常运作的区别:
- 项目是一次性的,日常运作是重复进行的
- 项目是以目标为导向的,日常运作是通过效率和有效性体现的
- 项目是由特定团队工作完成的,而日常运作是职能式的线性管理
- 项目存在大量的变更管理,而日常运作往往按部就班
6.软件项目的特点:
- 逻辑实体
- 相互作用的系统
- 变更
- 渐近明细
7.软件项目核心要素:过程、资源、干系人、结果
8.软件项目的核心生产力及其软件机构的核心能力:过程和人
9.实现项目目标的制约因素:
- 范围
- 进度
- 成本
- 客户满意度
成本和进度是效率问题,范围和用户满意度是效果。
10.管理的5项基本职能:
- 计划
- 组织
- 协调
- 指挥
- 控制
11.项目管理的5要素:
- 技术
- 方法
- 团队建设
- 信息
- 沟通
12.项目管理的范围
- 战略上的范围
- 人员(招聘,团队精神,组织文化)
- 问题(PM的主要任务之一就是发现和解决问题)
- 过程(是对技术、工具、人员的有效集成,过程管理时PM的任务之一)
- 战术范围
- 确定需求
- 在范围、进度、成本、质量之间寻求最佳平衡点
- 在不同的项目干系人之间寻求最佳平衡点
13.项目管理分为三部分:
- 战略决策——从宏观上帮助企业明确和把握发展方向的管理
- 日常运营——对日常性、重复性工作的管理
- 项目管理——对一次性、创新性工作的管理
12.过程管理与项目管理之间的关系:
-
项目管理用于保证项目的成功,
-
过程管理用于管理最佳实践。
-
这两项管理不是相互孤立的,而是有机地紧密地结合的。
-
过程管理的成果可以辅助项目管理。
-
项目管理得到的有关过程使用的数据是过程改进和参考和依据。
13.干系人:参与项目,或其利益因项目的实施或完成而受到积极或消极影响的个人和组织,并且他们会对项目的目标和结果施加影响。
14.软件项目相对于其他项目的特殊性。
(1)产品的特殊性
- 逻辑实体
- 复杂
- 知识密集
- 没有老化和磨损,生命周期长,变更大,维护成本高
(2)过程和方式的特殊性
- 人力密集
- 沟通代价高
- 可复用的成分少
- 成本估算和控制困难
- 维护代价高
15.敏捷模型核心价值(了解,无需背,多考选择题)
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
16.敏捷模型核心价值(了解,无需背,多考选择题)
课本P19
17.(课后题)请简述项目管理的5个过程组及其关系。
- 5个过程组是指启动、计划、执行、控制、结束。
- 关系:各个过程组通过其结果进行连接,一个过程组党的结果或输出是另一个过程组的输入。其中,计划过程组、执行过程组、控制过程组是核心管理过程组。
第一篇 项目初始
1.项目立项的过程
分为三个阶段:立项建议阶段、立项评审阶段、立项筹备阶段。
其中立项建议阶段首先是产品构思、立项调查、可行性分析的迭代进行,然后进行申请立项,接着进入立项评审阶段进行评审,最后进入立项筹备阶段进行项目筹备。
在(立项)阶段,应该明确项目的目标、时间表、使用的资源和经费,而且得到项目发起人的认可。
2.在招投标阶段,甲方过程包括招标书定义、供方选择、合同签署,乙方过程包括项目分析、竞标、合同签署。
甲方的主要任务是招标书定义、供方选择、合同签署,乙方的主要任务是进行项目选择。
3.项目启动的过程
- 项目授权(制定项目章程)
- 项目生命周期选择
- 识别干系人
4.项目章程的定义
项目章程是组织高层批准的一份书面的确认项目存在的文件,包括对项目的确认、对项目经理的授权和项目目标的概述。
4.项目经理的责任
- 开发计划(负责制定项目整体技术、负责审核各个子计划)
- 组织实施(选择并确定团队)
- 项目控制(监督检查、风险管理、处理问题)
5.项目经理的权利
-
进行项目的有关决策(最基本、最重要的权利)
-
挑选项目成员的权利(组件项目团队)
-
对项目资源进行再分配
6.项目经理的能力
PMI人才三角:①技术项目管理②领导力③战略和商务管理
7.常用的生存期模型
- 瀑布Waterfall——适用于需求明确、解决方案明确的项目
- V模型V-shaped——适用于需求明确、解决方案明确并且对系统的性能安全要求严格的项目
- 原型Prototyping——适用于初始时项目需求不明确,需要减少项目需求的不确定性的项目
- 增量Incremental——适用于初始时项目需求大部分已经确定,但对市场和用户把握还不够
- 螺旋式Spiral——适用于常常受风险制约的项目
8.项目生存期模型的分类
- 预测型——瀑布模型、V模型
- 适应型
- 迭代型——原型模型
- 增量型——增量模型
- 敏捷型——Scrum、XP、DevOps
9.选择生存期的步骤
- 熟悉各种生存期模型
- 评审、分析项目的特性
- 选择适合项目的生存期模型
- 标识生存期模型与项目不一致地方,并进行裁减
10.(课后题)写出3种你熟悉的生存期模型,并说明这些模型适用什么情况下的项目。
(1)瀑布模型
适用于软件功能需求明确的项目,即一般适用于功能明确、无重大变更的软件项目。如公司的财务系统、短期项目。
(2)V模型
适用于项目需求在项目开始时需求明确,解决方案也明确,并且项目对系统的安全性要求严格,如航天飞机系统、公司的财务系统。
(3)原型模型
适用于项目的需求在项目开始前不明确,需要减少项目的不确定性的项目。
第二篇 项目计划
(一)范围计划
1.项目管理计划中的核心三计划
- 范围计划
- 进度计划
- 成本计划
2.工作包:包含在WBS的最低层次的计划要完成的工作或可交付成果。
3.软件需求的层次
4.软件工程基本任务
软件需求工程分为需求开发和需求管理,需求开发主要进行需求获取,编写规格说明,需求建模,需求验证,需求管理主要进行建立基线、需求跟踪、变更控制。
5.一个工作包可以分配给另一个项目经理去完成。(注:工作包应当由唯一主体负责,可以分配给另外一位项目经理通过子项目的方式完成。)
6.WBS提供了项目范围基线,是范围变更的重要输入。
7.任务分解的形式
- 提纲式WBS
- 组织结构图式WBS
- 能说明层次结构的其他形式
8.(课后题)任务分解方法
- 模板参照
- 类比——对于类似的项目,可使用此方法
- 自顶向下——若对项目比较熟悉或者对项目大局有把握,可以使用此方法
- 自底向上——若对项目人员来说这是个崭新的项目,可以使用此方法
9.(课后题)任务分解的步骤
- 确定并分解项目的组成要素
- 确定分解标准
- 生存期
- 功能组成
- 确定分解是否详细
- 检验分解结果的标准
- 最底层的要素是否是实现目标的充要条件
- 最底层要素是否有重复的
- 每个要素是否清晰完整定义
- 最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排
- 检验分解结果的标准
- 确定项目交付成果
- 验证分解的正确性(建立编号)
10.(课后题)当项目过于复杂时,可以对项目进行任务分解,这样做的好处是什么?
将一个项目分解成更多的工作细目或者子项目,可以使项目变得更小、更易管理、更易操作。
(二)成本计划
1.成本的构成
- 直接成本——与具体项目相关的成本,如人员薪资等。
- 间接成本——不能具体到某个项目的成本,如水电费,房租,员工福利等。
2.软件规模的估算方法
- 传统的结构化程序设计方法:代码行(Lines of code, LOC)、功能点(Function Point, FP);
- 面向对象软件开发方法:特征点估算方法,3D功能点估算方法,全功能点估算方法,用例点估算方法和对象点估算方法;
3.成本与规模的关系
-
规模是成本的主要因素,是成本估算的基础。一般来说规模估算和成本估算是同时进行的
-
有了规模就确定了成本
4.成本估算的基本方法
-
代码行、功能点
-
类比(自顶向下)估算法
- 估算人员根据以往的完成类似项目所消耗的总成本(或工作量),来推算将要开发的软件的总成本(或工作量),然后按比例将它分配到各个开发任务单元中
- 使用情况
- 有类似的历史项目数据
- 信息不足(要求不是非常精确)的时候
- 在合同期和市场招标时
-
自下而上估算法
- 利用任务分解结构图,对各个具体工作包进行详细的成本估算,然后将结果累加起来得出项目总成本。
- 使用情况
- 项目开始以后,WBS的开发阶段
- 需要进行准确估算的时候
-
三点估算法
- 适用于考虑项目的不确定性和风险的项目
- 计算公式
- 贝塔分布:预期成本CE=(CO+4CM+CP)/6
- 三角分布:预期成本CE=(CO+CM+CP)/3
- CO:最乐观成本;CM:最可能成本;CP:最悲观成本
-
参数模型估算法
- 一种使用项目特性参数建立数据模型来估算成本的方法,是一种统计技术,如回归分析和学习曲线。
- 使用情况
- 存在成熟的项目估算模型
- 应该具有良好的数据库数据为基础
-
Delphi专家估算法
-
流程
-
组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格,请他们估算
-
专家详细研究软件规格说明后,对该软件提出3个规模的估算值
-
最小ai
-
最可能的mi
-
最大bi
-
-
组织者对专家的表格中的答复进行整理
-
计算每位专家的Ei=(ai+4mi+bi)/6
-
综合结果后:E=E1+E2+…En/n(N:表示N 个专家)
-
再组织专家无记名填表格,比较估算差,并查找原因
-
如果各个专家的估算差异超出规定的范围(例如:15%),则需重复上述过程,最终可以获得一个多数专家共识的软件规模
-
-
举例
-
某多媒体信息查询系统—专家估算
-
专家1:1,8,9=〉(1+9+4* 8 )/6=7(万元)
-
专家2: 4, 6 , 8=〉(4+8+4*6)/6=6 (万元)
-
估算结果=(6+7)/2=6.5(万元)
-
-
-
猜测估算法
5.参数模型估算法——功能点估算法
系统分为5类组件和一些常规系统特性。前3类组件是外部输入(EI)、外部查询(EQ)、外部输出(EO),另外两类组件是内部逻辑文件(ILF)、外部接口文件(EIF)。
6.参数模型估算法——COCOMO模型
COCOMO81模型将项目的模式分为有机型(相对较小、较简单的项目)、嵌入型(通常与硬件设备紧密联系,规模任意,对数据结构、算法要求较高,比如航天用控制系统、大型指挥系统)和半嵌入型(指各类实用项目,比如编译器、连接器、分析器)3种类型。有3个等级的模型,即基本模型(在项目相关信息极少时使用)、中等模型(在需求确立后使用)和高级模型(在设计完成后使用)。
基本模型:
-
公式
-
\[E=a*KLOC{^b} \]
-
E是所需的人力(人月),
-
KLOC是交付的代码行
-
a、b是依赖于项目自然属性的参数:
-
-
a、b的取值一般题目中会给表,让你去查
-
中等模型
-
公式
-
\[E=a*KLOC{^b}*F \]
-
E为所需的人力(人月)
-
a、b是系数
-
乘法因子F是根据成本驱动属性打分的结果,对公式的校正系数。F为所有成本驱动因子按照不同等级取值的乘积。(若成本驱动因子等级为正常,说明取值为1)
-
-
(三)进度计划
1.进度管理的过程
- 定义活动
- 排列活动顺序
- 两个活动间逻辑关系有4种,分别是
- 结束------>开始(FS)
- 结束------>结束(FF)
- 开始------>开始(SS)
- 开始------>结束(SF)
- 确定依赖关系的主要依据
- 强制性依赖关系——是合同所要求的或本身存在的、无法改变的逻辑关系。又称为硬逻辑关系。例如,需求分析一定要在软件设计之前完成,测试活动一定要在编码任务之后完成。
- 选择性依赖关系(软逻辑关系)——人为和主观确定的。在活动排序时要考虑某项应用领域的最佳实践和一些特殊排序的要求。例如,在信息系统集成项目中,是先进行网络布线后进行代码编写,还是先进行代码编写后进行网络布线,可以由项目管理团队根据人员安排情况进行确定;在软件开发项目中,是先进行数据库设计后进行软件模块设计,还是先进行软件模块设计后进行数据库设计,也可以由软件开发团队根据人员安排情况进行确定。
- 外部依赖关系——项目活动和非项目活动的依赖关系,往往取决于项目外部的任何第三方的逻辑关系。例如,政府部门的批准、供货商的供货等。再比如,在一个典型的系统集成项目中,如果买方自己负责设备采购,系统测试活动就与设备采购活动之间具有外部依赖关系。因为如果设备采购不到位,系统测试就无法进行,而设备采购活动不由卖方决定。
- 内部依赖关系——例如,只有机器组装完毕,团队才能对其测试。
- 两个活动间逻辑关系有4种,分别是
- 估算活动资源
- 估算活动持续时间
- 常用方法
- 定额估算法(适用于小规模项目)
- 经验导出模型
- PERT(工程评估评审技术)
- PERT历时=(O+4M+P) / 6;
- O是活动(项目)完成的最小估算值,或者是最乐观值;P是完成的最大估算值,或者是最悲观值;M是完成的最大可能估算值。
- 由于此方法有一定的风险,所以引入了标准层和方差的概念,往往会出项目在多少天内完成的概率是多少,这就用到了正态分布,具体见课本P160-P161
- 专家判断法
- 类比估计法
- 基于承诺的进度估算方法
- Jones的一阶估计准则
- 常用方法
- 制定进度计划
- 实质是:规定项目活动的计划开始和结束时间,并确定相应的里程碑。
- 步骤
- 进度编制
- 资源调整
- 成本预算
- 计划优化调整
- 计划基线
- 进度编制的基本方法
- 关键路径法(CPM)
- 利用正推法计算每个活动的ES、EF,利用逆推法计算每个活动的LS、LF;关于ES、LS、EF、LF的含义见课本P165
- 计算浮动时间
- 计算网络图中的最长路径
- 时间压缩法
- 应急法(赶工法)——用于权衡成本与进度间的得失关系,以决定如何以最小增量成本达到最大量的时间压缩。
- 时间成本平衡(进度压缩单位成本方法)
- 结合课本P170 例3理解并掌握此方法
- 进度压缩因子成本方法
- 结合课本P171的解释
- 时间成本平衡(进度压缩单位成本方法)
- 平行作业法(快速跟进法)——改变活动间的逻辑关系,并行开展某些活动。
- 应急法(赶工法)——用于权衡成本与进度间的得失关系,以决定如何以最小增量成本达到最大量的时间压缩。
- 关键链法——与关键路径法不同,关键路径法是工作安排尽可能开始,尽可能提前,而该方法是尽可能推迟。
- 关键路径法(CPM)
- 控制进度
2.项目进度估算的基本方法
- 基于规模的进度估算
- 定额计算法
- 经验导出方程
- PERT
- CPM——与PERT相比,更为准确
- 基于进度表的进度估算
- 基于承诺的进度估算
- Jones的一阶估算准则
- 其他策略
(四)质量计划
1.质量定义
质量是满足要求的程度,包括符合规定的要求和满足顾客隐含需求.
2.软件质量特性
- 功能性——软件所实现的功能达到它的设计规范和满足用户需求的程度;
- 性能效率——在规定条件下,用软件实现某种功能所需的计算机资源(包括时间)的多少;
- 可靠性——在满足一定条件的应用环境中,软件能够正常持续工作的能力;
- 安全性——为了防止意外或人为的破坏,软件应具备的自身保护能力;
- 易用性——对于一个软件,用户在学习、操作和理解过程中所做努力的程度;
- 可维护性——当环境改变或软件运行发生故障时,为了使其恢复正常运行所做努力的程度
- 可扩充性——软件扩充新功能的难易程度;适应需求变化的能力
- 可移植性——为使一个软件从现有运行平台向另一个运行平台过度所做努力的程度
- 重用性——整个软件或其中一部分能作为软件包而被再利用的程度
- 可信性——软件可信性是软件运行时使用质量属性的综合,决定了软件在实际条件下使用时,满足明确和隐含要求的程度
- 兼容性
3.质量的形成
质量形成于产品或服务的开发过程中,而不是事后的检查(开发后的测试)。所以通过这句话可以得知软件质量不能通过后期测试来提高。
4.质量成本
- 预防成本(一致性成本):评估和预防费用
- 缺陷成本(非一致性成本):改正缺陷的成本
质量过失比=预防成本/缺陷成本
5.质量管理的对象
- 过程质量——项目所有的过程,比如需求、设计、编码、测试、交付和部署等过程;
- 产品质量——文档和程序等。
6.软件质量管理过程
- 软件质量计划
- 方法
- 试验设计(采用统计学方法)
- 正交试验法——利用正交表合理安排和分析多种因素的方法,它用较少的试验次数获得较优的结果
- 优选法——以较少的实验次数迅速找到试验的最佳方案,如黄金分割法
- 标杆分析——基准对照(是一种寻找最佳实践的方法,是利用其他项目的实施情况作为当前项目性能衡量的标准)
- 质量成本分析——质量的效费比分析
- 流程图方法——可以显示系统的各种成分是相互的关系,帮助我们预测在何处可能发生何种质量问题
- 因果分析图——描述相关的各种原因和子原因如何产生潜在问题或影响,将影响质量问题的“人员、设备、参考资料、方法、环境”等各方面的原因进行细致的分解,方便地在质量计划中制定相应的预防措施
- 试验设计(采用统计学方法)
- 方法
- 软件质量保证
- 主要任务:检查项目过程和产品与预定的规范和标准是否一致;关键是它只是评价;
- 目的:验证在开发过程中是否遵循了合适的过程和标准。
- 注意:这个任务本身并不能提高产品的质量。一般由质量保证部门人员实施。
- 例如,审计(是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比较)。
- 软件质量控制
- 目的是发现和消除软件产品的缺陷,例如:评审和测试。
- 注意:这个任务本身提高产品的质量。一般由开发人员实施。
- 要点
- 检查工作结果
- 按照质量标准跟踪检查
- 确定措施,消灭质量问题
- 方法
- 评审
- 测试
7.(作业题)简述质量保证的主要活动,以及质量保证的要点。
质量保证的主要活动:
- 项目执行过程审计
- 项目产品审计
要点:
- 对项目进行评价
- 推测能否达到质量指标
- 建立对项目的信心
8.简述质量保证(QA,Quality Assurance)和质量控制(QC,Quality Control)的区别。
-
质量保证是后期质量活动,质量控制是前期质量活动;
-
质量保证是针对项目实施过程的管理手段,质量控制是针对项目产品的技术手段;
-
实施质量保证是针对过程改进和审计的,强调的是过程改进和信心保证。实施质量控制是按照质量要求,检查具体可交付成果的质量,强调的是具体的可交付成果。
(五)配置管理计划
1.配置管理简述
- 记录软件产品的演化过程
- 确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置。
- 最终保证软件产品的完整性、一致性、追朔性、可控性
2.软件配置项(SCI)
-
定义:是项目需定义其受控于软件配置管理的款项。每个项目的配置项也许不同。
-
软件配置项举例
-
系统规格说明书
-
软件需求规格说明书
-
设计规格说明书
-
源代码
-
测试规格说明书
-
3.基线
- 定义:
- 一个(些)配置项形成并通过审核,即形成基线
- 基线提供了软件生存期中各个开发阶段的一个特定点,
- 基线标志开发过程一个阶段的结束和里程碑
- 基线修改需要按照正式的程序执行
4.配置控制委员会(SCCB)
是一个决策机构
- 评估变更
- 批准变更申请
- 在生存期内规范变更申请流程
- 对变更进行反馈
- 与项目管理层沟通
5.常用配置管理的工具
- ClearCase&ClearQuest
- PVCS
- Harvest
- CVS
- VSS
6.配置管理最终保证软件产品的(完整性)、(一致性)、(追溯性)、(可控性)。
7.(版本管理)、(变更管理)是配置管理的主要功能。
8.基线变更时,需要经过(SCCB)授权。
9.基线变更控制包括(变更请求)、(变更控制)、(变更批准/拒绝)、(变更实现)等步骤。
10.(完整性和可跟踪性)是软件配置管理的核心功能。
11.基线提供了软件生存期中各个开发阶段的一个特定点。
12.(课后题)写出配置管理的基本过程
-
配置管理计划;
-
配置项标识和跟踪;
-
配置管理环境建立;
-
创建和发布基线;
-
变更管理;
-
版本管理
-
配置审核;
-
配置状态统计;
13.(课后题)说明软件配置控制委员会(SCCB)的基本职责。
- 评估变更
- 批准变更申请
- 在生存期内规范变更申请流程
- 对变更进行反馈
- 与项目管理层沟通
14.简述配置管理在软件开发中的作用,并至少列举两项配置管理工具。
软件配置管理是软件项目管理的重要内容,也是保证软件质量的重要手段。它能够对软件开发过程进行有效管理和控制,从而实现软件产品的完整性、一致性、可控性,使产品极大程度地与用户需求相吻合。它能够控制、记录、追踪对软件的修改并形成规范文档,方便日后维护和升级,更重要的是能够保护代码资源,积累软件财富,提高软件重用率。
配置管理工具有:Harvest、Perforce、ClearCase、PVCS、CVS\SVN、VSS、Git。
15.(课后题)写出几个常见的软件配置项。
软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书。
(六)团队计划(人员与沟通计划)
1.影响项目进度、成本和质量的因素包括人、过程和技术;
2.项目组织结构的主要类型
-
职能型——最普遍的组织形式;适用于主要由一个部门完成或技术成熟的项目
-
职能型优点
-
可以充分发挥职能部门的资源集中优势
-
部门的专家可以同时为部门内不同项目使用
-
便于相互交流 , 相互支援
-
可以随时增派人员
-
可以将项目和本部门的职能工作融为一体
-
-
职能型缺点
-
项目和部门利益发生冲突,职能部门更重视本部门的目标,会忽视项目目标
-
资源平衡会出现问题
-
权利分割不利于各个职能部门的交流和团结协作
-
行政隶属关系使得项目经理没有充分的权利
-
-
图示
-
-
项目型——适用于风险较大或者有严格要求的项目,不适合人才匮乏和规模小的企业
-
项目型优点
-
项目经理对项目可以负全责
-
项目目标单一,可以以项目为中心,有利于项目顺利进行
-
避免多重领导
-
组织结构简单,交流简单,快速
-
-
项目型缺点
-
资源不能共享
-
各个独立的项目处于相对封闭状态,不利于公司政策的贯彻
-
对项目组织的成员缺少一种事业上的连续性和安全感
-
项目组织之间处于分割状态,缺少信息交流
-
-
图示
-
-
矩阵型——适用于管理规范、分工明确的企业或者跨职能部门的项目。
-
矩阵型优点
-
专职的项目经理负责整个项目 , 以项目为中心,
-
公司的多个项目可以共享各个职能部门的资源
-
即利于项目目标的实现,又利于公司目标方针的贯彻
-
项目成员的顾虑减少了
-
-
矩阵型缺点
-
容易引起职能经理和项目经理权力的冲突
-
资源共享也能引起项目之间的冲突
-
项目成员有多头领导
-
-
图示
- 弱矩阵型图示
- 强矩阵型图示
- 弱矩阵型图示
-
3.干系人(stakeholder)是能影响项目决策、活动或者结果的个人、群体或者组织,以及会受到或者自认为会受到项目决策、活动或者结果影响的个人、群体或者组织。
4.项目沟通的基本原则
- 及时性
- 准确性
- 完整性
- 可理解性
5.项目沟通的方式
- 书面沟通和口头沟通
- 语言沟通和非语言沟通
- 正式沟通和非正式沟通
- 单向沟通和双向沟通
- 网络沟通
6.(课后作业)写出5种以上项目沟通方式。
- 书面沟通和口头沟通
- 语言沟通和非语言沟通
- 正式沟通和非正式沟通
- 单项沟通和双向沟通
- 网络沟通
7.(课后作业)对于特别重要的内容,一般采用哪些方式才能确保有效地沟通。
对于特别重要的内容,要采用多种方式进行有效沟通确保传达到位,除发送邮件外还要电话提醒、回执等,重要的内容还要通过举行各种会议进行传达。
(七)风险计划
1.风险的2个基本特征
- 不确定性
- 损失
2.项目风险的3要素
- 风险事件
- 风险事件发生的概率
- 风险造成的影响
3.风险类型
-
预测角度
-
已知风险——Known known
-
可预测风险 ——Known unknown
-
不可预测风险——unknown unknown
-
-
范围角度
-
项目风险
-
技术风险
-
商业风险
-
4.风险的基本性质
- 风险的客观性
- 风险的不确定性
- 风险的不利性
- 风险的可变性
- 风险的相对性
- 风险同利益的对称性
5.风险管理的四个过程
-
风险识别
-
方法及工具
-
德尔菲方法
-
头脑风暴法
-
情景分析法
-
面谈法
-
风险条目检查表
-
检查表法是利用检查表作为风险识别的工具
-
检查表法是根据风险要素建立软件项目的风险条目列表
-
列表中列出所有与风险因素有关的提问
-
可以使管理者集中识别常见的类型中的已知和可预测的风险
-
有研究表明:IT项目常常存在一些共同的风险源
-
基于生存期的检查表
-
初始阶段
-
设计阶段
-
实施阶段
-
收尾阶段
-
-
-
-
-
风险评估(掌握决策树分析即可)
-
风险规划
- 主要策略
- 回避风险——是对所有可能发生的风险尽可能的规避,采取主动放弃或者拒绝使用导致风险的方案。例如,放弃采用新技术;
- 转移风险——是为了避免承担风险损失,有意识将损失或与损失有关的财务后果转嫁出去的方法。例如,出售、分包、开脱责任合同、保险。
- 损失控制——一般分为两种情形,损失预防和损失抑制
- 自留风险——由项目组织自己承担风险事故所致损失的措施
- 主要策略
-
风险控制