管理信息系统讲义 系统开发项目管理 哈尔滨工业大学 张洁 第六章 项目时间管理 ? 活动定义 指确认一些特定的工作。通过完 成这些活动就完成了工程项目的各项目细 目。 ? 活动排序 明确各活动间的相互联系性。 ? 活动工期估计 估计各活动所需时间。 ? 进度安排 分析活动间排序，活动所需时间 和资源以作出项目进度计划。 ? 进度控制 控制项目进度变化。 进度规划 进度规划子过程。 1.确定项目的各项活动（项目分解结构最底层的工 作块） 2.确定活动顺序 —找出各项活动之间的依赖关系。 3.时间估算 —估算各项活动所需要的时间。 4.编制时间进度计划 —研究和分析活动顺序，活动 时间和资源要求，进而制定项目时间进度计划。 6.1活动定义 进一步细化WBS，改变细化的角度，从可交 付成果到活动。 1）活动清单 2）对项目工作分解结构的修改和补充。 6.2确定活动顺序 1.活动之间的逻辑关系 （1） 强制性依赖关系。 （2） 可灵活处理的关系。约定 ①软逻辑关系。 ②优先逻辑关系。 （3） 外部依赖关系。 2. 活动顺序安排的表现方法 CPM、PERT、GERT和VERT可以统称为网络（计划）技术。 3. 网络样板 示例项目的活动 序号 活动 工期 紧前活动 1 2 3 4 5 6 7 8 9 10 A 1 工作日 B 2 工作日 C 3 工作日 D 4 工作日 1 E 5 工作日 2 F 4 工作日 2 G 6 工作日 3 H 6 工作日 4,5 I 2 工作日 7 J 3 工作日 6,9,8 双代号网络图（ AOA） ? Arrow diagramming method (ADM)箭线图 ? Activity-on-arrow (AOA) 1 4 3 6 7 2 8 5 A=1 B=2 C=3 F=4 E=5 D=4 I=2 H=6 J=3 G=6 单代号网络图 (AON) ? Precedence diagramming method (PDM).前导图 ? activity-on-node (AON) 1 A 6 G 5 E 2 B 4 F 2 I 3 C 4 D 6 H 3 J 依赖关系的类型 1、结束对起始 FS——前一活动必须在后一 活动开始前结束。 2、结束对结束 FF——前一活动必须在后一活 动结束前结束。 3、起始对起始 SS——前一活动必须在后一 活动开始前开始。 4、起始对结束 SF——前一活动必须在后一 活动结束前开始。 网络计划技术搭接关系 ? 准确描述活动间关系 – FS, SS, FF, SF 6.3时间估计 为了估计各活动所需时间，需要广泛收集历 史数据。 编制进度计划 影响进度计划制定的因素: ①强制日期。 ②关键事件和主要里程碑。 ③假设前提。 示例项目信息 公司 ABC系 统 集成公 司 当前日期 2004-11-10 标题 示例项目 工期 16 工作 日 项目开始时间 2004-11-10 8:00:00 项目完成时间 2004-12-1 17:00:00 6.3.1关键路线法(CPM) （ 1）关键路线定义 （2）确定关键路线 最早开始和最早结束时间 1、最早开始时间（ earliest start time,ES)是指某项 活动能够开始的最早时间。 2、最早结束时间 (earliest finish time, EF)是指某项 活动能够完成的最早时间。 EF=ES+工期估计 规则 ：某项活动的最早开始时间必须相同或晚于直 接指向这项活动的最早结束时间中的最晚时间。 最迟开始和结束时间 1、最迟结束时间（ latest finish time,LF)是指为 了使项目在要求完工时间内完成，某项活动必 须完成的最迟时间。 2、最迟开始时间（ latest start time,LS)是指为了 使项目在要求完工时间内完成，某项活动必须 开始的最迟时间。 LS=LF-工期估计 （ LS和 LF通过反向推出） 规则 ：某项活动的最迟结束时间必须相同或早于该活动直接指向的 所有活动最迟开始时间的最早时间 。 网络计划技术正向计算 ? 正向计算 – 目的：计算最早时间 – 方法：根据逻辑关系 ? 方向：从网络图始端向终端计算 ? 第一个任务的开始为项目开始时间 ? 任务完成时间为开始时间加持续时间 ? 后续任务开始时间根据前置任务的时间和搭接时间而 定 ? 多个前置任务存在时，根据最迟的任务时间定 正向计算结果 ? 示例：正向计算结果 -最早时间 ? 图： 正向计算后的网络数据（最下排显 示 的 数据是最早开始日期和最早完成日期 ） 示例项目关键路径单代号网络图 最迟完成 时间 最早开始 时间 持续时间 最早完成 时间 最迟开始 时间 总时差 任务名称 1 A 6 G 5 E 2 B 4 F 2 I 3 C 4 D 6 H 3 J 示例项目关键路径单代号网络图 最迟完成 时间 最早开始 时间 持续时间 最早完成 时间 最迟开始 时间 总时差 任务名称 0 1 1 A 3 6 9 G 2 5 7 E 0 2 2 B 2 4 6 F 9 2 11 I 0 3 3 C 1 4 5 D 7 6 13 H 13 3 16 J 网络计划技术反向计算 – 反向计算 - 计算最晚时间 – 目的：计算最晚时间 – 方法：根据逻辑关系 ? 方向：从网络图终端向始端计算 ? 最后一个任务的完成时间为项目完成时间 ? 任务开始时间为完成时间减持续时间 ? 前置任务完成时间根据后续任务的时间和搭接 时间而定 ? 多个后续任务存在时，根据最早的任务时间定 反向计算结果 ? 示例：反向计算结果 -最晚时间 ? 图： 反向计算后的网络数据（最下排显示的 数据是最晚开始日期和最晚完成日期 ） 示例项目关键路径单代号网络图 最迟完成 时间 最早开始 时间 持续时间 最早完成 时间 最迟开始 时间 总时差 任务名称 3 0 1 1 2 2 A 11 3 6 9 5 2 G 7 2 5 7 2 0 E 2 0 2 2 0 0 B 13 2 4 6 9 7 F 13 9 2 11 11 2 I 5 0 3 3 2 2 C 7 1 4 5 3 2 D 13 7 6 13 7 0 H 16 13 3 16 13 0 J 有关时差定义 时差（ slack):在不影响项目最后完成时间的前提下， 某活动可以推迟开始的最大时间量。 总时差（ total slack,TS)： 在不影响项目最后完成 时间的前提下，项目可以推迟开始的最大时间量。 TS=LF-EF或 LS-ES 自由时差（ free slack):某项活动在不影响其紧随活 动最早开始时间的情况下，可以延迟的时间量， 这是指向同一活动的各项活动时差之间的相对差 值。 FSi=minESi+1-EFi 关键路径（ critical path) 关键路径： 从项目开始到项目完成有许多条 路径，在整个网络图中最长的路径就叫关 键路径。 非关键路径（ noncritical path): 在整个网络图中非最长的路径都叫非 关键路径 。 确定关键路径 ? 确定关键路径：找出那些具有最小时差的活动 ? 总时差 = 最晚开始时间 - 最早开始时间 = 最晚完成时间 - 最早完成时间 – 时差等于 0和小于 0的任务组成关键路径 – 可以改变确定关键路径的条件 ?那些具有正总时差的路径是非关键路径。 确定关键路径 ? 时差计算和关键路径确定 ? 多重关键路径条件设置（工 具 /选项 /计算方式） 示例项目关键路径 最迟完成 时间 最早开始 时间 持续时间 最早完成 时间 最迟开始 时间 总时差 任务名称 3 0 1 1 2 2 A 11 3 6 9 5 2 G 7 2 5 7 2 0 E 2 0 2 2 0 0 B 13 2 4 6 9 7 F 13 9 2 11 11 2 I 5 0 3 3 2 2 C 7 1 4 5 3 2 D 13 7 6 13 7 0 H 16 13 3 16 13 0 J 示例项目甘特图 甘特图表示的关键路径 6.3.2计划评审技术（PERT） PERT(计划评审技术， Program Evaluation an Review Technique) 是 50年代末美国海 军部开发北极星潜艇系统时为协调 3000多 个承包商和研究机构而开发的，其理论基 础是假设项目持续时间以及整个项目完成 时间是随机的，且服从某种概率分布。 PERT可以估计整个项目在某个时间内完成 的概率。 PERT和 CPM在项目的进度规划中 应用非常广 活动的工期估计 ? 工序、工期三值估计 To (乐观估计 Optimistic Time) Tm(最可能估计 Most likely Time) Tp(悲观估计 Pessimistic Time) β 概率分布 （beta probability distribution ) 工序期望工期 t e = 6 4 0 tPtmt ++ 工序工期方差 δ 2 = 2 0 6 ? ? ? ? ? ? ? ? ?tt p 总工期期望值 ∑ = cp e e t T 总工期方差 ∑ = CP T σσ 22 根据概率论中心 极 限定律 总 工期服从 正 态分布 工序工期的 β分布图 概率 1 5 6 时间估计 15 时间估计10 15 20 根据概率论中心极限定律总工期服从正态分布 ? 总工期的正态分布示图 99% p -3δ -2δ -1δ 0 1δ 2δ 3δ Te 68% 95% 概率 示例项目的工期估计 活动 TO TM TP T A 0.5 days 1 day 2 days 1.08 days B 1 day 2 days 3 days 2 days C 2 days 3 days 4 days 3 days D 2 days 4 days 5 days 3.83 days E 2 days 5 days 7 days 4.83 days F 3 days 4 days 8 days 4.5 days G 3 days 6 days 9 days 6 days H 2 days 6 days 9 days 5.83 days I 1 day 2 days 3 days 2 days J 1 day 3 days 4 days 2.83 days 工期=2+3.83+5.83+2.83=14.5 方差 1.97 标准差 1.4 示例概率分析 -正态分布 根据正态分布规律，在±σ范围内即在 13.09天与 15.90天之间完成的概率为 68％； 在± 2σ范围内完即在 11.69天到 17. 30天完成的概率为 95％； 在± 3σ范围内即 10.28天到 18.71天完成的概率为 99％。 如果客户要求在 10天内完成，则可完成的概率几乎为 0，也就是说，项目有 不可压缩的最小周期，这是客观规律 10.28 11.69 13.09 14.33 15.90 17.30 18.71 正态曲线下最大横坐标之间的面积和 Z值表 Z 0.00 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 00 0000 0.00399 ---- ---- ---- ----- ------ ----- ----- 0.03586 01 0.03983 --- ---- ---- ----- ---- ------ ---- ------ 0.07535 02 -------- -------- -- ------ ------ -- ------ ------ 1.4 0.41924 --- ---- ---- ----- ----- ------ 0.42922 ----- 0.43189 1.5 -------- -------- -- ------ ------ -- ------ --- ---- ---- ----- ---- ------ ---- ------ -------- 6.4进度计划编制成果： （1)项目进度计划。 （2)项目进度计划图形 甘特图，网络图, 里程碑图, 时标网络图。 （3）辅助详细资料 1.按时段提出的资源要求，常以资源直方 图的形式出现。 2.替代时间计划 3.进度后备或进度风险估计。 （4）进度管理计划。 （5）资源要求更新。 关键路径的管理 ? 关键路径的控制 ? 缩短项目进度的技术 – 赶工 Crashing，以提高成本为代价 – 快速跟进 Fast tracking，部分活动并行方法 ? 更新关键路径数据 示例项目关键路径单代号网络图 变为 4天 最迟完成 时间 最早开始 时间 持续时间 最早完成 时间 最迟开始 时间 总时差 任务名称 3 0 1 1 2 2 A 9 3 6 9 3 0 G 7 2 3 5 4 2 E 4 0 2 2 2 2 B 11 2 4 6 7 5 F 11 9 2 11 9 0 I 3 0 3 3 0 0 C 7 1 4 5 3 2 D 11 5 4 9 7 2 H 14 11 3 14 11 0 J 变为 3天 CP变为 14天 6.5控制进度计划的变更 ? 进度计划的实际检查 – 进度计划的审查。 IT项目的估计不现实 ? 计划时每种资源使用 75%， Monson – 项目干系人进展会议。避免突兀的变化 ? 处理人的问题 – 授权、激励、纪律和协商 ? 许多项目的失败是由人造成的，而不是由于没有画 出一张漂亮的 PERT图 . ? ---Bolton Bart 实践的问题思考 -里程碑 ? 项目里程碑 – 客户要求 – 项目特点 – 激发团队士气 – 风险管理 ? 缺点 – 误用目标管理 – 里程碑控制不严 – 里程碑的设定忽视了项目干系人的利益 局部偏差的影响 活动甲 活动乙 活动丙 活动丁 5 10 0 活动甲 活动乙 活动丙 活动丁 5 10 -1 25 25 25 2525 50 75 100 0 25 25 25 2525 50 75 100 0 20 40 60 80 100 120 12345 人 计划 累计 机器计划 累计 19 21 28 32 19 40 68 100 0 19 21 25 25 19 40 65 90 0 20 40 60 80 100 120 12345 人实际 累计 机器实际 累计 关键资源的利用 20天 A 10天 A B A B B C C C b) a) A B C 10天 10天 10天 c) 第七章 项目成本管理 ? 在项目的实施过程中，为了保证完成项目 的实际成本不超过其预算成本而展开的项 目成本估算、项目预算和成本控制方面的 管理活动。 项目成本管理 ? 1 资源计划过程 决定完成项目各项活动需 要哪些资源 (人、设备、材料 )以及每种资源 的需要量。 ? 2 成本估算过程 估计完成项目各活动所需 每种资源成本的近似值。 ? 3 成本预算过程 把估计总成本分配到各具 体工作。 ? 4 成本控制过程 控制项目预算的改变。 7.1 项目成本 1. 项目成本 ? 一般项目的成本主要由项目直接成本、管 理费用和期间费用等组成。 1) 项目直接成本是指与项目有直接关系的成本 费用。例如，直接人工费、直接材料费、其 他直接费用等。 2) 管理费用是指为了组织、管理和控制项目所 发生的费用。例如，管理人员费用支出、差 旅费、固定资产和设备使用费、办公费、医 疗保险费，以及其他一些间接费用。 3) 期间费用是指不受项目业务量增减影响的费 用，如日常行政管理费、销售费等。 ?IT 软件项目由于项目自身的特点，对整 个项目的预算和成本控制更为困难。 IT 软件项目的成本有 4 种： 1) 硬件 /支持软件成本：包括项目所需的所有 硬 件设备 、 系统软件 、 数据资源 的购置、运输、 储存、安装、测试的费用。对于进口设备， 还要包括国外运费、保险费、进口关税和增 值税等费用。 2) 差旅及培训费：培训费用包括 开发人员培训 费 和 用户培训费 。 3) 软件开发成本 ： 人工成本 是最主要的软件开 发成本。在软件开发项目中，付给软件工程 师的人工费用占了开发成本的绝大部分。 4) 项目管理费用 ：用于项目组织、管理、控制 的费用支出。 ? 尽管硬件 /支持软件成本、差旅及培训费 用可能在项目总成本中占较大的成本，但 最主要的成本还是指在 开发过程中所花费 的工作量及相应的代价 ，它不包括原材料 及能源的消耗。主要是人的劳动消耗。 ?IT 软件项目的产品生产不是一个重复的 制造过程，而是以 “一次性 ”开发过程所花 费的代价来计算的 。 项目资源计划 ? 反映项目的各个阶段中，各项活动的资源 种类，每种资源的数量质量和资源投入时 间。 ? 人月神话 : 增加人员 --〉增加工期 资源计划编制方法 ? 专家判断 ? 定额法 ? 资料统计法 ?WBS ? 资源均衡法 某种资源的使用量波动幅度较大常意味着 该种资源短缺的概率增加。 稳定的资源需求 ---〉低的资源成本 7.2成本估算 成本估算就是编制一个为完成项目各活动所必 须的资源成本的近似估算。当项目根据合同进行 时，应当注意将估算和报价区别开来： ? 成本估算是编制对可能定量成果的评估 —为了 提供产品或服务，执行组织要付出多少成本。 ? 报价是一种经营决策 —这种产品或服务，执行组 织要收取多少成本 —成本估算仅为作出该决策应 该考虑的因素之一。 成本估算包括确定和考虑各种不同的成本估 算替代方案。 成本估算的工具和技术 ? 类比估算法，也称自上而下估算是指利 用以前类似项目的实际成本作为估算当 前项目成本的基本依据。 ? 参数模型法，是指将项目特征参数用于 数学模型来预测参数。 cocomo ? 自下而上的估算，这种方法先估算各个 单位工作的独立成本，然后将各个工作 的估算自下而上汇总估算出项目总成本。 ? 计算机工具。 软件 库存情况更新 开发者 W.Ward 日期 2 / 8 / 82 阶 段 项目任务 工作量分布 (%) 小计 (%) 计划和需求 软件需求定义 9.43 开发计划 1.89 11.32 产品设计 11.32 产品设计 初 步 的 用户手册 5.66 测试计划 1.89 18.87 详细 PDL描述 7.55 详细设计 数据定义 7.55 过程设计 3.77 正 式 的 用户手册 3.77 22.64 编码与 程序编码 11.32 单元测试 单元测试结果 18.87 30.19 集成与 编写文档 7.55 系统测试 集成与测试 9.43 16.98 总 计 100 7.3 成本预算 ? 项目成本预算是项目成本控制的基础， 它 a) 将项目的成本估算分配到项目的各项具体 工作上，以确定项目各项工作或活动的成 本定额。 b) 制定项目成本的控制标准。 c) 规定项目意外成本的划分与使用规则。 ? 项目成本预算包括四部分： 直接人工费 用 的预算； 咨询服务费用 的预算； 资源 采购费用 的预算； 意外成本 的预算。 7.4成本控制的内容 ? 对造成成本基准计划变化的因素施加影响，以保证这种变 化朝着有利的方向发展； ? 确定成本基准计划是否已发生变化； ? 在实际变化发生时，对这种变化实施管理。 成本控制包括： ? 监视成本执行以寻找出与计划的偏差； ? 确保所有有关变更都准确地记录在成本基准计划中； ? 防止不正确、不适宜或未核准的变更纳入成本基准计划中。 ? 将核准的变更通知有关项目干系人。 7.5软件成本估算模型 单个模块开发工作 （开发平台为 Lotus Domino/Notes） 序号 模块 开发周期（中 级程序员） 代码行长度 数据库大小 (无数据 ) 1. 办事指南 0.25人月 300 1170K 2. 名片簿 0.25人月 300 1039K 3. 合同管理 0.25人月 460 2110K 4. 物控管理 0.5人月 850 2560K 5. 组织机构 0.5人月 900 1318K 6. 流程管理 0.8人月 1000 2304K 7. 公告板 0.5人月 1400 2560K 8. 人事管理 1人月 1800 3840K 9. 公文管理 1.8人月 2500 2304K 10. 事务审批 1.5人月 3750 2110K 11. 考勤管理 1.8人月 4800 3840K 12. 资源管理 1.8人月 5800 3840K 13. 会议管理 2.5人月 11000 4608K 软件项目开发工作 软件项目 开发周期 包含的模块 备注 某政府客户 3个人月 10个 定制开发量较 小 某媒体客户 6个人月 17个有3个模块完全 重新开发 某金融客户 10个人月 14个 80%完全重新开 发 某保险客户 16个人月 18个 完全重新开发 分析 ? 从表一中可以看出，模块的代码行越长，开发周期就越长，对同一开 发工具而言基本是一个线形关系，但其中也要考虑代码重用问题，比 如一个模块代码很长，但是可能包含了很多公用函数，那么在估算时 就应适当减少代码行数量，表中会议管理就是个例子，这个模块的代 码行超过一万行，但其中公共函数很多，去除此因素，真正的代码行 在 9000行左右。 ? 表二是软件项目的实际开发周期（不考虑系统实施），从普通意义上 说软件项目中包含的功能模块越多、越复杂，或者说软件越大开发周 期增长的就越快，这个时间绝不是模块开发时间的简单叠加，因为模 块功能数量的增加直接带来了软模块间相互关联度、复杂度的成倍增 加，这就直接导致了在需求、设计等阶段需要花费更多的时间，这比 单独考虑一个模块复杂的多。在表二中随着模块数量增加，开发周期 增加不是特别明显，这是因为产品化程度高所引起的，由于相当数量 的模块可以完全重用，实际开发量大大减少，最后一个例子完全重新 开发，开发周期就长的多。 COCOMO模型 ? COCOMO（ COnstructive COst MODEL） 由美国的 B． W. Boehm在其 1981年出版的 专著 “软件工程经济学 ” 书中提出，该模型是 在对美国加利福尼亚 63个不同应用领域中 的软件开发项目进行详尽分析的基础上建 立起来的一个分层次结构化成本测算模型。 ? COCOMO模型包括基本模型（ BASIC MODEL）、中级模型（ Intermediate MODEL）和详细模型（ Detailed MODEL） 等三个子模型。 COCOMO基本模型 ? COCOMO基本模型成本测算的基本原理是： 根据最终交付的源代码数来计算开发工作 量，并进而估计开发工期 ? 基本公式： MM（ Man－ Month）代表人月数 KDSI（ Kilo-Delivered Source Instruction）千行源代码数： TDEV（ Time Of Development）开发时间，以月为单位； C1， C2， K1， K2 常量参数采用不同开发方式，它们的取值 不同 COCOMO基本模型 假设前进大学计算中心受校方委托开发规模为 5 kDSI （行源代码）的工资管理软件系统，计划采用组织型 方式进行开发 ,计算结果为： 开发方式 C1 K1 C2 K2 Organic,组织的 2.4 1.05 2.5 0.38 Semi-detached， 半分离的 3.0 1.12 2.5 0.35 Embedded，嵌入式的 3.6 1.2 2.5 0.32 软件开发类型 ? 组织型：一个软件开发小组在一个很熟悉 的内部环境里开发软件。人员之间很熟悉， 对有关系统熟悉．所开发的软件代码多数 在 5万行以下。 ? 半分离型：介于有机型和嵌入型之间，或 是两种方式的混合体。项目特性也可能属 于中间级别。软件规模可到 30万行。 ? 嵌入型：主要不同是这种软件项目必须在 紧密的约束下运行。对硬件、其它软件、 操作规程等有强耦合关系。 COCOMOII简单估算法 B KSLOCAPM KSLOCAPM ×= ×= PM-人月 KSLOC-千行源代码数 A-生产率因子 B-惩罚因子 COCOMOII简单估算法 工程类型 生产率因子 惩罚指数 COCOMOII默认 2.94 1.052 嵌入式开发 2.58 1.110 电子商业开发 3.60 1.030 网络开发 3.30 1.030 军事开发 2.77 1.030 15ksloc行代码的电子商务开发： 无惩罚指数计算 PM=3.60*15=54人月 有惩罚指数计算 PM=3.60*15 1.030 =58.6人月 FPA方法 ?FPA是一种用来度量软件系统规模的方法。 在 FPA中，任何一个软件系统都被看作是由 外部输人处理、外部输出处理．外部查询 处理．内部逻辑文件和外部参照文件五种 要素组成。估算系统中这五种要素的个数， 并乘以适当的权值（权值即为每个要素的 功能点数）就可以计算出系统的功能点数， 进而估算出系统的规模。在 FPA中用到的信 息系统模型。 FPA中用到的信息系统模型 FP例子 功能与源代码行数的关系 语言 SLOC/FP C++ Default 53 COBOL Default 107 Delphi 5 18 HTML4 14 Visual Basic 6 24 SQL Default 13 Java 2 Default 46 IBM模型 (Walston-Felix) ?E ＝ 5.2× (KLOC)0.91 D ＝ 4.1× (KLOC) 0.36 ＝ 14.47× E0.35 S ＝ 0.54× E0.6 DOC ＝ 49× (KLOC) 1.01 KLOC是千源代码行数， E是工作量 (PM)， D 是项目持续时间 (月 )， S 是人员需要量 (人 )， DOC是文档数量 (页 ) 挣值法（Earned Value) BCWS:计划工程预算费用或计划工程投资额 Budget Cost for Work Scheduled ? 即项目实施过程中某阶段计划要求完成的工作所需的预算费用。在计 算 BCWS时，我们通常假设项目的任意一项活动费用的支出都是均匀 的 . ? BCWS＝计划完成项目活动工作量×单位工作量预算定额 BCWP:完成工程预算费用或实现工程投资额 Budget Cost for Work Performed 即项目实施过程中某阶段按实际完成工作及按预算定额计 算出来的费用，即挣得值（ Earned value） BCWP＝已完成的项目活动工作量×单位工作量预算定额 ACWP:完成工作实际费用或消耗工程投资额 Actual Cost for Work Performed 偏差 费用偏差(Cost Variance) CV=BCWP-ACWP 当 CV为负值时表示项目的实际费用支出超过预算 值，即项目超支了。当 CV为正值时表示项目实际 支出低于预算值，即项目费用有节余。 进度偏差(Schedule Variance) SV=BCWP-BCWS 当 SV为正值时表示项目的实际进度比计划提前了。 当 SV为负值时表示项目实际进度比计划滞后了。 业绩指标 费用业绩指标 (Cost Performed Index) CPI=BCWP/ACWP ? 当 CPI＞ 1时，表示项目节支了； ?CPI＜ 1时，表示项目超支了； ?CPI＝ 1时，表示项目实际费用支出与预算吻合 进度业绩指标(Schedule Performed Index) SPI=BCWP/BCWS ? 当 SPI＞ 1时，表示项目进度提前了； ? SPI＜ 1时，表示进度滞后了； ? SPI＝ 1时，表示实际进度等于计划进度 测量项目进展的挣值法 ACWP BCWS BCWP 落后进度 A C B D BCWP－ ACWP 超支的费用 S曲线 总预算费用 测量时间 总计划时间 挣值法例 项目 X 时间 任务 123456789 活动 A 活动 B 活动 C 活动 D 第六周末预算与实际支出 活动 预算费用 实际支出 活动 A 100 90 活动 B 150 110 活动 C 200 100 活动 D50 0 项目 X挣值参数表 活动 预算费用 BCWS ACWP BCWP 活动 A 100 100 90 100 活动 B 150 150 110 75 活动 C 200 100 100 125 活动 D50 0 0 0 合计 500 350 300 300 SV=BCWP-BCWS=300-350= -50 CV=BCWP-ACWP=300-300=0 总体上看，项目进度滞后了，但费用却按计划支出了 项目最终费用和进度结果预测 ? 项目最终费用和进度结果的预测方法有两种。 ? 一种是根据当前已经完成的数据对项目进行重新分析和计划。这种方 法通常用于当过去的项目实施情况显示了原有的估计或假设条件基本 失效的情况下。 ? 另一种方法是利用挣得值数据来估算。当然，最好的方法还是将这两 种方法结合起来使用。 ? 假设原先对项目总费用的预算为 BAC，则项目完工时的总费用（ EAC） 可以预测为 ? EAC＝ BAC/CPI ? 假设原先对项目工期的计划为 SAC，则项目最后可能结束的工期 （ EAS）可以预测为 ? EAS＝ SAC/SPI ? 这种方法的问题在于，它用一种线性的方式，根据当前的趋势预测未 来。更好的办法是对每项项目任务进行重新估算，然后再对项目的费 用和工期进行预测，但它仍不失为一种能够快捷判断目前项目状态的 方法 项目 X的差值分析 CPI=BCWP/ACWP=300/300=1 SPI=BCWP/BCWS=300/350=0.857 EAC=BAC/CPI=500/1=500 EAS=SAC/SPI=9/0.857=10.5周 项目费用仍为500，工期为10.5周 某项目挣得值数据表 BCWS BCWP ACWP SPI CPI 5月 15日 50000 50650 50650 1.01 1 5月 30日 110000 95000 100000 0.86 0.95 6月 15日 250000 235000 256000 0.94 0.92 6月 30日 1500000 1480000 1560000 0.99 0.95 7月 15日 1750000 1750000 1850000 1 0.95 7月 30日 4570000 4590000 4805600 1 0.96 8月 15日 5200000 5300000 5550000 1.02 0.95 8月 30日 5600000 5800000 5865000 1.04 0.99 9月 15日 6200000 6100000 6500000 0.98 0.94 9月 30日 6358520 6358529 6650000 1 0.96 费用偏差趋势图 0.75 0.8 0.85 0.9 0.95 1 1.05 5 月 1 5 日 5 月 3 0 日 6 月 1 5 日 6 月 3 0 日 7 月 1 5 日 7 月 3 0 日 8 月 1 5 日 8 月 3 0 日 9 月 1 5 日 9 月 3 0 日 SPI CPI IDEAL 项目偏差控制 BCWP CV CV =% BCWS SV SV =% -10 -5 7.5 15 低于预算 15 7.5 -5 -10 进度延后 项目团队 管理区域 中层管理区域 高层 管理 区域 高于预算 2005-7-20 第八章项目质量管理 ? 项目质量管理实为了保证该项目能够兑现 它的关于产品和服务的承诺而进行的管理 活动。它包括 “在质量体系中，确定质量工 作的方针、目标和责任的全部活动，并通 过诸如质量计划、质量保证和质量提高等 手段来完成这些活动 " 2005-7-20 质量是管出来的 2005-7-20 项目质量管理的内容 ? 1 质量计划 确定哪些质量标准适用于该项 目，并决定如何达标。 ? 2 质量保证 在常规基础上对整个项目执行 情况作评估，以提供信用，保证该项目将 能够达到有关质量标准。 ? 3 质量控制 监控特定项目的执行结果，以 确定它们是否符合有关的质量标准，并确 定适当方式消除导致项目质量令人不满意 的原因。 8.1质量基本知识 2005-7-20 项目质量和项目产品质量 项目质量管理必须设计对项目和项目产品质 量两个方面的管理。任何方面没能满足质量要求 都将对部分或全部项目干系人造成严重的消极后 果。如： ? 通过项目队伍加班以达到客户要求，可能因增加 雇员交接班次数产生消极后果。 ? 通过突击而缩短规定的质量检验过程以达到项目 进度目标，如果缺乏未能被发现，将造成消极后 果。 2005-7-20 何谓质量 ? 反映实体满足明确和隐含需要能力的特征 总和。 --ISO ? 要求的一致性（ conformance to requirements） ? 适用性（ Fitness for use） 2005-7-20 质量和等级 质量和等级不能混淆。等级是 “对功能用途相 同但质量要求不同的实体所作的分类和排序 ”。低 质量是须解决的问题，低等级则不是。例如，软 件产品可以是高质量（无明显性错误、可读性好 的文件）和低等级（有限的功能）；或是低质量 （许多故障、组织差的顾客手册）和高等级（大 量功能）。确定和传达所需的质量和等级标准水 平是项目经理和项目队伍的责任。 2005-7-20 质量管理的发展 ? 一、传统质量管理阶段 –“操作者的质量管理 ” ? 二、质量检验管理阶段 – 1918年，泰勒，执行质量管理的责任就由操作者转移给工长。有 人称它为 “工长的质量管理 ” ? 三、统计质理管理阶段 – 利用数理统计原理，预防产出废品并检验产品质量的方法，由专 职检验人员转移给专业的质量控制工程师承担。这标志着将事后 检验的观念改变为预测质量事故的发生并事先加以预防的观念。 ? 四、现代质量管理阶段 – 现代质量管理追求顾客满意，注重预防而不是检查，并承认管理 层对质量的责任 ? 使用性能，现在又增加了耐用性、美观性、可靠性、安全性、可信性、 经济性等要求 ? 全面质量管理，强调执行质量职能是公司全体人员的责任，应该使企 业全体人员都具有质量意识和承担质量的责任 2005-7-20 质量管理名人 ? W. Edwards Deming——戴明 ? Joseph M. Juran——朱兰 ? Philip B. Crosby——克鲁斯比 ? Koaru Ishikawa ——石川馨 ? Genichi Taguchi ——田口原一 ? Arnold V.Feigenbaum ——非根堡姆 2005-7-20 克劳士比的质量管理四项基本原则 ? 原则一、什么是质量？ –·质量即符合要求，而不是好。 – 质量的定义就是符合要求而不是好。 “好、卓越、美丽、独特 ”等描 述都是主观和含糊的。 ? 原则二、质量是怎样产生的？ –·预防产生质量 ,·检验不能产生质量 ? 原则三、什么是工作标准？ –·零缺陷，而不是 “差不多就好 ” – 零缺陷作为一种心态：第一次就事情做对；避免双重标准； “决不 允许有错误 ”； “我们非常重视预防 ”；我们只有在符合全部要求时 才能 OK。 ? 原则四、怎样衡量质量？ –·不符合要求的代价（金钱），而不是指数 – 不符合要求的代价：当要求没有符合时产生的额外的费用。不符 合要求的代价是浪费的代价：浪费时间、心力和物资。这是不必 要的代价。 2005-7-20 各种图表 2005-7-20 8.2质量计划编制 1、质量管理计划，应描述项目队伍如何执行其质量 方针，描述项目的质量管理体系： “实施质量管理 的组织结构、责任、程序、过程和资源 ”。质量计 划为项目总体计划提供输入，并必须陈述项目的 质量控制、质量保证和质量提高。 2、操作定义，以非常专用的词汇描述某事物是什么， 并在质量控制过程中是如何对其进行测量的 。 3、检查表，通常是特定工业或活动，用于核实一系 列要求的步骤是否已经实施的结构化工具。 2005-7-20 8.3质量保证 质量保证是在质量体系中实施的全部有计划、 有系统的活动，以提供满足项目相关标准的信心。 它应贯穿于整个项目。 ?质量保证指建立绩效标准，然后根据这些标准衡量 和评估项目的执行情况。 ?质量保证可以检验对高质量产品或服务生产流程控 制的有效性和效率。 ?质量保证在产品的生命周期的每个阶段都进行。 ?质量保证与质量控制平行进行。 2005-7-20 8.4质量控制的方法和技术 1 ? 检查 —包括为确定结果是否符合需求所采 取的诸如测量、检查和测试等活动。 ? 控制图 ? 帕累托图 ? 因果图（石川图、鱼骨图） ? 检查表 2005-7-20 软件的测试 2005-7-20 ?质量控制图 比萨饼的质量控制图 2 0 2 控制上限 控制下限 百分比null % null 1 2 3 4 5 6 7 天数 烹饪火候不足或过火的比萨饼的百分比 2005-7-20 排列图（帕累托定律） ? 帕累托定律： – 80% 的问题是由于 20%原因造成的 ? 帕雷托图是一种柱状图。图中数据根据重 要性按递减顺序排列，通常按频率的量级、 成本、时间或类似的参量。 ? 帕雷托图通过显示时间的频率或成本来帮 助确定关键因素，以引起必要的关注。 2005-7-20 ?帕累托图（ Pareto charts) 35 30 25 20 15 10 5 交货时凉 了 烹制欠火 候 服务与交货 太慢 放错调 料 劣质服 务 比萨饼店的帕累托图（时期一周） 缺陷事 件 数 量 起因频率 累计百分比 100 50 25 75 缺陷事 件 百 分 比 2005-7-20 帕累托图（ Pareto charts) 汽车轮胎的损坏 2005-7-20 软件的问题 2005-7-20 复印机的问题 2005-7-20 因果图（石川图、鱼骨图） 时间 方法设备 较大缺陷 材料 环境人员测量精力 2005-7-20 用户不能进入系统 2005-7-20 检查表 2005-7-20 质量控制的方法和技术 2 ? 统计抽样 —选取收益总体的一部分进行检查。 ? 流程图 —用于帮助分析问题是如何产生的。 ? 趋势分析 —根据历史结果，利用数学技术预测未 来的成果。趋势分析经常用于监控： 1、技术执行情况 —鉴定出了多少错误或缺陷，还剩 多少没得到纠正。 2、成本和进度执行情况 —在一段时间内，完成了多 少有重大偏差的活动。 2005-7-20 抽样统计与标准差 ? 总体（ population） –所有的要测量的样品 ? 样本（ Sample） –接受测试的部件，我们 可能无法对总体进行测试，因为这样可能 会： – 成本太高 – 时间太长 – 太具破坏力 –(我们相信不会有很多缺陷 ) 2005-7-20 样本大小 ? 样本大小 = 0． 25 X（可信度因子 /可接受误差） 2 ? 可信度因子表示被抽样的数据作本变化的可信度。 ? 例如，假定上述电子数据交换系统开发者将接受一个 95％ ? 的可信度： ? 样本大小 = 0． 25 x （ 1.96/0.05） 2 ＝ 384。 ? 如果开发者想要 90％的可信度，样本大小如下： ? 样本大小 =0． 25 x（ 1． 645/0.10） 2＝ 68 ? 如果开发者想要 80％的可信度，样本大小如下： ? 样本大小 =0． 25 X （ 1.28/0.20） 2 ＝ 10 2005-7-20 正态分布曲线 2005-7-20 8.5提高 IT项目的质量 ? 领导 ? 质量成本 ? 组织影响、工作环境 ? 成熟度模型 – 能力成熟度模型 – 项目管理成熟度模型 ? 软件配置管理 2005-7-20 领导 ?“最重要的是上层管理应当有质量头脑。如果上层 管理不表示出特殊的兴趣，那么，下面几乎什么 也不会发生 ”。 ----朱兰 1945 ? 由于经济的全球化和顾客的要求越来越高，快速 创造价格合理的高质量产品对于企业的生存非常 重要。拥有好的质量能够帮助公司保持竞争力。 ? 大部分质量问题出在管理上而非技术上。因此， 上级管理部门必须承担产生、支持和促进质量计 划的责任。 2005-7-20 质量成本 ? 为了使项目满足或超过项目相关的质量标 准或者项目干系人的期望所发生的成本。 ? 一致成本表示为了交付满足要求和适用性 的产品的成本，包括预防成本，评估成本 ? 不一致成本表示因为故障或没有满足质量 期望的成本，故障成本 2005-7-20 软件缺陷引起的停机成本 89,500$ 航空公司预订中心（小型） 90,000 $ 价目表销售中心 69,000 $ 电话卡销售 28,250 $ 包裹运输业务 14,500$ 自动取款机（中等银行） 每小时停机成本业务 2005-7-20 质量成本 ? 预防成本 (Preventive Cost) – 质量计划工作费用 – 供应商调查 – 培训费用 ? 评估成本 (Appraisal Cost) – 来料检查 – 检查和试验费用 – 保持试验设备精度费用 – 耗用的材料和劳务 – 存货估价费用 ? 缺陷成本 (Failure Cost) ?1 内部缺陷成本 (Internal) – 废品损失 – 返修损失 – 复试费用 – 停工损失 – 产量损失 – 处理费用 ?2 外部缺陷成本 (External) – 申诉受理费用 – 退货损失 – 保修费用 – 折让费用 质量成本实际分布 10% 35% 48% 7% Prevention cost Appraisal cost Internal cost External cost 质量成本理想分布 70% 15% 10% 5% Prevention cost Appraisal cost Internal cost External cost 2005-7-20 组织影响、工作环境 ? 德马库和里斯特（ Lister）的一项研究得出了一些有关组织与相对生 产率的有趣结果。 – 德马库和里斯特进行了一项称为 “编码战争游戏 ”的研究，这项研究开始于 1984年并延续了好几年，来自 92个组织的 600多位软件开发员参与了这 项游戏。设计这个游戏是为了在二个广泛的组织、技术环境和编程语言 范围内，检查编程质量和生产效率。研究证明，组织方面的问题比技术 环境或编程语言对生产率的影响作用更为重大。 ? 参与者的生产效率大相径庭，相差十倍以上。 – 一个团队在 1天内可以完成的编码项目，而另一个团队却需要花费 10天时 间。 ? 来自同一组织的软件开发者，生产效率变化只有 21％。 – 如果从一个特定组织来的一个团队在 1天内能够完成的编码项目，那么以 同一组织来的另一团队最长在 1.21天内肯定能够完成。 ? 生产率与编程语言、工作经历、薪水之间没有联系。 ? 此外，研究还表明，提供专注的工作空间和安静的工作环境是提高生 产率的关键因素。研究结果建议高级管理者应努力改善工作环境以提 高生产效率和质量。 2005-7-20 CMM 软件能力成熟度模型 Capability Maturity Model 2005-7-20 CMM的发展 ? 软件能力成熟度（ the Capability Maturity Model for Software, 简称 CMM）是美国软 件工程研究所（ Software Engineering Institute, 缩写为 SEI）首先提出的。 1987年 在美国国防部支持下，卡内几 —梅隆大学 率先推出了软件过程评估项目的研究成果 — —软件过程能力成熟度模型 CMM。很快就 引起了软件界的广泛关注，并在此后引发 了一系列反响，以至在其基础上形成了国 际标准（ ISO/IEC 15504）。 2005-7-20 CMM的思想 ?CMM的基本思想是基于已有 60多年历史的产品质 量原理。 – 希袄特（ Walter Shewart）在 30年代发表了统计质量控 制原理，戴明和朱兰的关于质量的著作又进一步发展 和论证了该原理。 – 实际上，将质量原理变为成熟度框架的思想是克劳斯 比，他在著作 “Quality is Free”首先提出，他的质量管 理成熟度网络描绘了采用质量实践时的 5个进化阶段， – 该框架后来又由 IBM的拉迪斯（ Rom Radice）和他的 同事们在汉弗莱 (Watts Humphrey)指导下进一步改进 以适应软件过程的需要。 – 1986年，汉弗莱将此成熟框架带到了 SEI并增加了成熟 度等级的概念，将这些原理应用于软件开发，发展成 为软件过程成熟度框架，形成了当前软件产业界正在 使用的框架。 2005-7-20 CMM的意义 ? 迄今为止学术界和工业界公认的有关软件 工程和管理实践的最好的软件过程。 ? 为评估软件组织的生产能力提供了标准。 ? 为提高软件组织的生产过程指明了方向。 2005-7-20 CMM的改进数据 5.0:1 4.0:1~8.8:1 收益比 39% 10%—94% 发布后的缺陷（减少 /年 ） / 15%—23% 上市时间（提早 /年） 35% 9%—67% 生产率提高 /年 平均范围类别 2005-7-20 不成熟软件组织与成熟软件组织的 比较 试等保证质量的活动 成熟的软件组织不成熟的软件组织名称 产品质量有保证，软件 过程有纪律，有必要的 支持性基础设施 问题判断无基础，难 预；进度滞后时，常 减少或取消评审、测 质量管理 有历史数据和客观依据 ，比较准确 无实际根据，硬件限 定时，常在质量上作 让步 进度、经费 估计 主动式，监控产品质量 和顾客满意程度 反应式（消防式）管理方式 有统一标准，且切实可 行，并不断改进；通过 培训，全员理解，各司 其职，纪律严明 。 临时拼凑、不能贯彻软件过程 内容 2005-7-20 CMM概述 9 一个成熟软件组织具有在全组织范围内管理软件、开发过 程和维护过程的能力 9 规定的软件过程被正确无误地通知到所有员工 9 工作活动均按照已规划的过程进行，并通过可控的先导性 试验和费效分析使这些过程得到改进 9 对已定义过程中的所有岗位及其职责都有清楚的描述 9 通过文档与培训使全组织有关人员对已定义的软件过程都 有很好的理解，从而使其软件过程所导致的生产率和质量 能随时间的推移得到改进。 2005-7-20 CMM的结构 2005-7-20 CMM的一些基本概念（ 1） ? 软件过程 ：人们用于开发和维护软件及其相关过程的一 系列活动，包括软件工程活动和软件管理活动。 ? 软件过程能力 ：描述（开发组织或项目组）遵循其软件 过程能够实现预期结果的程度，它既可对整个软件开发 组织而言，也可对一个软件项目而言。 ? 软件过程性能 ：表示（开发组织或项目组）遵循其软件 过程所得到的实际结果，软件过程性能描述的是已得到 的实际结果，而软件过程能力则描述的是最可能的预期 结果，它既可对整个软件开发组织而言，也可对一个特 定项目而言。 ? 软件过程成熟 ：一个特定软件过程被明确和有效地定义， 管理测量和控制的程度。 2005-7-20 CMM的一些基本概念（ 2） ? 软件能力成熟度等级 ：软件开发组织在走向成熟的途中几 个具有明确定义的表示软件过程能力成熟度的平台。 ? 关键过程域 ：每个软件能力成熟度等级包含若干个对该成 熟度等级至关重要的过程域，它们的实施对达到该成熟度 等级的目标起到保证作用。这些过程域就称为该成熟度等 级的关键过程域，反之有非关键过程域是指对达到相应软 件成熟度等级的目标不起关键作用。归纳为：互相关联的 若干软件实践活动和有关基础设施的一个集合。 　 2005-7-20 CMM的一些基本概念（ 3） ? 关键实践 ：对关键过程域的实践起关键作用的方针、规程、 措施、活动以及相关基础设施的建立。关键实践一般只描 述撟鍪裁磾而不强制规定撊绾巫鰯。整个软件过程的改进 是基于许多小的、渐进的步骤，而不是通过一次革命性的 创新来实现的，这些小的渐进步骤就是通过一些着关键实 践来实现。 ? 软件能力成熟度模型 ：随着软件组织定义、实施、测量、 控制和改进其软件过程，软件组织的能力也伴随着这些阶 段逐步前进，完成对软件组织进化阶段的描述模型。 2005-7-20 CMM模型 2005-7-20 CMM模型 2005-7-20 CMM模型 2005-7-20 CMM五级模型 (1) ? 第一级：初始级 – 在初始级，企业一般不具备稳定的软件开发与维护的 环境。常常在遇到问题的时候，就放弃原定的计划而 只专注于编程与测试。 – 软件过程的特点是杂乱无章，有时甚至混乱， 几乎没有明确定义的步骤，成功完全依赖个人 努力和英雄式核心人物，管理是反应式（消防 式）。 　　 2005-7-20 CMM五级模型 (2) ? 第二级：可重复级 　　建立了基本的项目管理过程来跟踪成 本、进度和功能特性，制定了必要的过程 纪律，能重复早先类似应用项目取得成 功。 2005-7-20 CMM五级模型 (3) ? 　　第三级：定义级 　　 管理和工程的软件过程已文件化、标准 化，并综合成整个软件开发组织的标准软 件过程。所有项目都采用根据实际情况修 改后得到的标准软件过程来发展和维护软 件。 2005-7-20 CMM五级模型 (4) ? 　　第四级：定量管理级 　 制定了软件过程和产品质量详细的度量标 准。软件过程和产品的质量都被开发组织 的成员所理解和控制。 2005-7-20 CMM五级模型 (5) 　第五级：（不断）优化级 　　加强了定量分析，通过来自过程 质量反馈和来自新观念、新科技的反 馈使过程能不断持续地改进。 2005-7-20 缺陷预防 技术变更管理 过程变更管理 过程的量化反馈和先进的新思想、新技术促 进过程不断改进 5 优化级 定量的过程管理 软件质量管理 收集对软件过程和产品质量的详细度量，对 软件过程和产品都有定量的理解与控制 4 已定量管理 级 组织过程定义 组织过程焦点 培训大纲 集成软件管理 软件产品工程 组织协调 同行专家评审 已将软件管理和工程文档化、标准化，并综 合成该组织的标准软件过程。所有项目 均使用经批准、剪裁的标准软件过程来 开发和维护软件。 3 已定义级 需求管理 软件项目计划 软件项目跟踪和监督 软件子合同管理 软件质量保证 软件配置管理 建立了基本的项目管理过程来跟踪费用、进 度和功能特性。制定了必要的过程纪律 ，能重复早先类似应用项目取得成功。 2 可重复级 软件过程是无序的，有时甚至是混乱的，对 过程几乎没有定义，成功取决于个人努 力。管理是反应式（消防式） 1 初始级 关键过程域特点过程能力等级 2005-7-20 关键过程域分类 无序过程1 初始级 需求管理 软件项目策划 软件项目跟踪和监督 软件子合同管理 软件质量保证 软件配置管理 2 可重复级 软件产品工程 同行专家评审 组织过程焦点 组织过程定义 培训大纲 集成软件管理 组织协调 3 已定义级 软件质量管理定量过程管理4 已定量管理 级 缺陷预防定量变更管理 技术变更管理5 优化级 工程（需求分析、 设计、测试等 ） 组织 （高级管理者 评审） 管理 （软件项目策划等） 过程分类 等级 2005-7-20 共同特征 ? 执行约定 描述组织保证过程得以建立和继续起作用所必须 采取的行动。执行约定一般包含制定组织的方针和规定高 级管理者的支持。 ? 执行能力 描述为了能实施软件过程，项目或组织中必须存 在的先决条件。执行能力一般包括资源、组织结构和培训。 ? 执行的活动 描述为实现一个关键过程区域所必须的角色和 规程。执行的活动一般包括制定计划和规程，进行工作， 跟踪它，并在需要时采取纠正措施。 ? 测量和分析 描述对过程进行测量和对测量结果进行分析的 需要。测量和分析一般包括一些为了确定所执行活动的状 态和有效性所能采用的测量的例子。 ? 验证实施 描述那些能保证遵照已建立的过程进行活动的措 施。验证一般包括管理者和软件质量保证部门所作的评审 和审计。 2005-7-20 CMM和 ISO9001的比较 ?CMM专为软件企业定制，而 ISO适用于各行各业 ? ISO9001确定了一个质量体系的最少要求 ?CMM明确强调持续的过程改进 ? 既有联系又有区别 ? 最重要的是保证企业产品质量并不断改进和提高 第九章 项目人力资源管理 ? 项目人力资源管理指能够充分发挥参与项 目的人员的作用管理程序。 ? 1组织的计划编制 确定书面计划和分配项目 任务、职责和报告关系。 ? 2人员获取 得到需要分配到项目中工作的 人力资源。 ? 3团队建设 提高个人和团队的技能以提高 项目资源。 9.1组织的计划编制 ? 内容： ? 对项目角色、职责以及报告关系进行识别、 分配和归档。 ? 产生： ? 责任分配矩阵： RAM ? 组织分解结构 : OBS ? 人员配置管理计划 大型项目组织结构图 项目经理 项目副经理 系统工程师 结构管理项目技术组独立检测组 质量保证 项目经理 项目经理 项目经理 组 1 组 2 组 3 组 1 组 2 组 1 组 2 职责分配矩阵（ RAM） WBS OBS 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 1.1.8 系统工程 RRP R 软件开发 RP 硬件开发 RP 测试工程 P 质量保证 RP 配置管理 RP 后勤支持 P 培训 RP R—责任组织单元 P—行动组织单元 项目干系人角色 RAM 干系人 事项 ABCDE 单元测试 SPA I R 整体测试 SPA I R 系统测试 SPA I R 用户认可测试 SP I AR A—负责人 P — 参与者 R — 要求审查 I — 要求输入 S —要求签字 人员配置管理计划 ? 组织计划编制的另一个输出结果是人员配置管理 计划。 ? 人员配置管理计划描述了项目组何时以及如何增 加和减少人员。 ? 这个计划可以是正式也可以是非正式的，其详细 的程度取决于项目的类型。 – 例如，人员配置管理计划就要描述项目所需人员的类 型，比如 Java程序员、商业分析师、技术文献书写员 等等，还包括每个月每种类型的人员所需的数量。 ? 人员配置管理计划通常包括资源直方 ——表示随 着时间分配给项目的资源数量的柱状图。 人力资源直方图 0 2 4 6 8 10 12 一月 二月 三月 四月 五月 六月 JAVA程 序 员 商业分析师 技术文献书写员 经理 数据分析师 测试专家 9.2人员获取 ?IT人员的 “紧缺 “ ? 1.IT技术人才 ? 2.IT管理人才 ?--如何留住人才 项目经理的权限和选聘（3） 项目经理要履行其职责，必须要有足够的 权限。 ? 选人要慎重，用人要信任。 “疑人不用， 用人不疑 ”。 ? 项目经理可从外部招聘，也可内部挑选。 ? “发现人才的方法是找那些最忙的人。” 选择合适的团队成员 ? 具有与项目相关的知识和技能 ? 个人对项目感兴趣并能兑现承诺 ? 有时间参与项目 ? 喜欢团队合作 资源负荷 资源平衡 资源平衡：合理地分配和使用资源 。 例子：项目网络图中标出了活动 A、 B、 C及其历时活动。 A 有 3天时差，活动 C有 2天时差。 假设活动 A有 2个员工，活动 B有 4个员工，活动 C有 2个员工 平衡结果 ? 如果活动 C延迟 2天开始的资源使用 9.3项目团队 ? 项目经理应该： 1、尊重和关怀所有员工 2、解决问题而不是责备人 3、召开经常和有效的会议 4、工作组 3-7人 5、计划一些社会活动，增进了解 6、强调同一性。创建成员喜欢的传统。 7、培训 8、认可个人和团队成绩。 项目团队建设活动 ? 体能挑战：军训，攀岩，漂流 ? 心理偏好： – 更多的公司是让团组参与智力方面的团队建设 活动，这样他们能更好地了解自己、了解他人 以及了解如何最有效地进行合作。 – 了解和重视每个人的不同点以便作为一个团队 更有效地工作，这是非常重要的。 – 在这些团队建设活动中常使用的一个练习就是 梅厄一布雷格类型指示器（ MBTI） ——一个决 定个人偏好的常用工具 信息系统开发人员 类型 信息系统开发 人员 普通人 内向型比例 思考型比例 75% 25% 85% 50% 凯西的理智 /思考型分类： 信息系统开发人员更有可能属于此类； 理智型一般倾向于学习科学、把学习技术当成爱 好，而且喜欢系统工作。 9.4人力资源管理的关键 ? 项目组生命期 ? 动机理论 ? 影响和权力 ? 提高有效性 ? 项目管理软件 项目组生命期 ? 形成期 礼貌 ? 风暴期 冲突 ? 规范期 磨合 ? 成果期 融洽，高产 ? 结束期 动机理论与激励 动机理论 自我成就 自我表现 归属、公认、尊重 安全、避护所、温暖、爱 生理、食、衣 马斯洛(Maslow) 层次需求论： 一种需求满足之后，新的 需求才会出现。 生理层次 安全层次 社会层次 自尊 自我实现 技术人员与管理人员的激励因素 序号 技术人员 管理人员 1 成就感 责 任感 2 发展机遇 成就感 3 工作乐趣 工作乐趣 4 个人生活 受认可的程度 5 成为技术主管的机会 发展机遇 6 技术领先 与下属关系 7 同事之间的关系 同 事之间的关系 8 受认可的程度 业务领先 9 工资 工资 10 责任感 操 控能力 项目经理影响员工 ? 泰穆汗和威廉姆对项目经理影响员工的方法做了研究 : 1. 权力 ——发命令的正当等级权力。 2. 任务 ——感知到的项目经理影响员工工作分配的能力。 3. 预算 ——感知到的项目经理授权他人使用自由支配资金 的能力。 4. 提升 ——提拔员工的权力 5. 资金 ——给员工涨工资和增加福利的权利 6. 处罚 ——感知到的项目经理实施处罚的能力 7. 工作挑战 ——根据员工完成一项特定任务的喜好来安排 工作的能力 8. 专门技术 ——感知到项目经理的重要的技术知识 9. 友谊 权力的种类 ? 合法的权力（ Legitimate Power） ? 强制力（ Coercive Power）惩罚、威胁 ? 专家权力（ Expert Power） ? 奖励权力（ Reward Power ） ? 感召力（ Referent Power） 影响力和权力作用结果 ? 泰穆汗和威廉姆发现，如果项目经理过多地用权 力、资金或者处罚的手段来影响人们，项目很有 可能会失败。而当项目经理使用富有挑战性的工 作和专门技术来影响员工，项目成功的可能性更 大。利用富有挑战性的工作来影响员工得到非常 有效的结果，这与马斯洛和匹兹伯格关于激励的 调查结果相一致。在一些包括某些特定知识的项 目中，比如大部分的 IT项目，专门技术作为影响 员工的一个手段可以发挥重要作用。 、 ? 影响力和权力是息息相关的。权力就是让员工做 不得不做的事的潜在影响力。权力比影响力在内 涵上更强烈些，因为权力往往用来让员工改变他 们的行为。 提高有效性的习惯 ? 独立的习惯培养 ?1保持积极的状态 ?2一开始就牢记结果 ?3最重要的事放在最重要的位置 ? 协作的习惯 ?4考虑双赢 ?5首先去理解别人然后再被理解 倾听 ?6协同 整体效应（和谐，手指） ?7磨快锯子 自我提高，培训 有成效项目团队的特点 ? 对项目目标的清晰理解 ? 对每位成员角色和职责的明确期望 ? 目标导向 ? 高度的合作互助 ? 高度信任 有效地管理时间 1、每个周末，找出几个（ 2-5个）下周要完成的目标。 2、每天结束时，列出第 2天要做的事情。 3、早晨的第一件事是看一下，并且整天都要看这个表。 4、控制干扰，不要让电话、邮件或随意来访者打扰你的工作。 5、学会说“不”。 6、有效利用时间（零碎时间） 7、尽量一次性处理大部分时间 8、周末，如果你完成了全部目标，就奖赏你自己。