系统集成项目管理工程师教程-第23章案例分析参考答案.pdf

案例一 人力资源负荷优化案例 问题 1 每天按照 8 小时工作制计算 游戏软件开发项目人力资源计算 序号 工作名称 人力资源类型 平均每天工作量 工时 每天需安排人数 1 需求分析 分析员 24 3 2 总体设计 设计员 48 6 3 界面详细设计 设计员 24 3 4 动画详细设计 设计员 24 3 5 处理详细设计 设计员 24 3 6 界面编码 程序员 40 5 7 动画编码 程序员 40 5 8 处理编码 程序员 40 5 9 界面单元测试 测试员 32 4 10 动画单元测试 测试员 32 4 11 处理单元测试 测试员 32 4 12 系统测试 设计员 16 2 测试员 32 4 13 项目管理 管理员 8 1 工作排序表 序号 工作名称 紧前事件 1 需求分析 2 总体设计 1 3 界面详细设计 2 4 动画详细设计 2 5 处理详细设计 2 6 界面编码 3 7 动画编码 4 8 处理编码 5 9 界面单元测试 6 10 动画单元测试 7 11 处理单元测试 8 12 系统测试 9 10 11 13 项目管理 活动网络图 人力资源负荷图 案例二 现金流分析案例 问题 1 计算该项目自投资当年起的静态投资回收期和动态投资回收期 要求列算式 并说明两者存在差异的原因 资金的时间价值 指货币随着时间的推移而发生的增值 也称为资金时间价值 现值 Present value 也称在用价值 指资产按照预计从其持续使用和最终 处置中所产生的未来净现金流入量折现的金额 通常又称 本金 通常记作 P 终值 future value 又称将来值或本利和 是指现在一定量的资金在未来某一时 点上的价值 通常记作 F 单利终值 F P P i n P 1 i n 式中 1 n i 单利终值系数 提示 除非特别指明 在计算利息时 给出的利率均为年利率 对于不足一年 的利息 以一年等于 360 天来折算 单利现值 现值的计算与终值的计算是互逆的 由终值计算现值的过程称为 折现 单利现 值的计算公式为 P F 1 ni 式中 1 1 ni 单利现值系数 复利终值 1 60 2 30 3 30 4 30 5 30 8 20 7 20 6 20 9 20 10 20 11 20 12 50 3 6 3 3 3 5 5 5 4 4 4 6 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 单位 双周 资源 人数 4 10 7 16 13 7 1 F P 1 i n n 表示 n 次方 在上式中 1 i n 称为 复利终值系数 用符号 F P i n 表示 这样 上式就可以写为 F P F P i n 复利现值 P F 1 i n n 表示负 n 次方 上式中 1 i n 称为 复利现值系数 用符号 P F i n 表示 投资回收期是指用投资方案所产生的净收益补偿初始投资所需要的时间 其单位 通常用 年 表示 静态投资回收期是不考虑资金的时间价值时收回初始投资所需要的时间 公式 P t 累计净现金流量开始出现正值的年份数 1 上一年累计净现金流 量的绝对值 出现正值年份的净现金流量 动态投资回收期是考虑资金的时间价值时收回初始投资所需的时间 公式 P t 累计净现金流量现值出现正值的年份数 1 上一年累计净 现金流量现值的绝对值 出现正值年份净现金流量的现值 投资回收率 1 动态投资回收期 100 题 1 答案 静态投资回收期 3 1 300 500 2 6 年 动态投资回收期 3 1 296 58 355 9 2 83 年 差异的原因 动态回收期考虑了资金的时间价值 而静态回收期未考虑 题 2 答案 投资回收率 1 2 83 35 3 20 投资是可行的 案例三 挣值分析案例 工作代号 工作名称 预算成本 千元 已完工作量 实际发生成本 千元 挣值 千元 A 产品总体设计 200 100 210 200 B 产品结构设计 220 100 220 220 C 控制系统设计 400 100 430 400 D 生产车间设计 250 100 250 250 E 辅助材料采购 300 100 310 300 F 压缩机外协 540 50 400 270 G 负离子发生器外协 840 100 800 840 H 零部件加工 600 100 600 600 I 整机装配 240 0 0 0 J 整机调试 150 0 0 0 K 车间土建施工 1600 40 800 640 L 车间设备安装 2000 0 0 0 M 工艺文件编制 100 100 90 100 N 项目验收 60 0 0 0 题 1 答案 工作代号 工作名称 预算成本 千元 已完工作量 实际发生成本 千元 挣值 千元 中 预算成本 PV 计划值 计划完成工作的预算成本 BCWS 实际发生成本 AC 实际成本 已完成工作的实际成本 ACWP 挣值 EV 已完成工作的预算成本 BCWP EV PV 已完工作量 题 2 答案 前 20 旬的挣值 EV 的累计 200 220 400 250 300 270 840 600 0 0 640 0 100 0 3820 题 3 答案 前 20 旬的实际成本 AC 的累计 210 220 430 250 310 400 800 600 0 0 800 0 90 0 4110 题 4 答案 CV EV AC 3820 4110 290 EV AC 实际成本大于预算成本 超支 SV EV PV 3820 200 220 400 250 300 540 840 600 240 150 1600 2000 100 3820 7440 3620 EV PV 实际进度小于计划进度 进度落后 题 5 答案 EAC 是根据项目绩效和定性风险分析确定的最可能的总体估算值 是既定项目工作完 成时 计划活动 WBS 组件或项目的预期或预见最终总估算 当前偏差被看成非典型的 以后不会发生类似偏差 公式 EAC AC BAC ev 当前偏差被看成是可代表未来偏差的典型偏差时 公式 EAC 累计 AC BAC EV 累计 CPI BAC 是完成工作所需要的预算 PV 本题适用第一种类型 EAC AC BAC ev 4110 7440 3820 7730 采取的措施 在软件开发项目中合理 有效地进行挣值管理 确定剩余工作的规模和工作量 确定剩余工作的需求 严格控制项目的进度和成本 在保证项目质量的前提下 进行的必要的赶工和成本缩减工作 案例四 需求评审案例 建议一 分层次评审 我们知道用户的需求是可以分层次的 一般而言可以分成如下的层次 目标性需求 定义了整个系统需要达到的目标 功能性需求 定义了整个系统必须完成的任务 操作性需求 定义了完成每个任务的具体的人机交互 目标性需求是企业的高层管理人员所关注的 功能性需求是企业的中层管理人员所关注 的 操作性需求是企业的具体操作人员所关注的 对不同层次的需求 其描述形式是有区别 的 参与评审的人员也是不同的 建议二 正式评审与非正式评审结合 正式评审是指通过开评审会的形式 组织多个专家 将需求涉及到的人员集合在一起 并定义好参与评审人员的角色和职责 对需求进行正规的会议评审 而非正式的评审并没有 这种严格的组织形式 一般也不需要将人员集合在一起评审 而是通过电子邮件 文件汇签 甚至是网络聊天等多种形式对需求进行评审 两种形式各有利弊 但往往非正式的评审比正 式的评审效率更高 更容易发现问题 因此在评审时 应该更灵活地利用这两种方式 建议三 分阶段评审 应该在需求形成的过程中进行分阶段的评审 而不是在需求最终形成后再进行评审 分 阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审 降低了需求返工的风 险 提高了评审的质量 比如可以在形成目标性需求后进行一次评审 在形成系统的初次概 要需求后进行一次评审 当对概要需求细分成几个部分 对每个部分进行各个评审 最终再 对整体的需求进行评审 建议四 精心挑选评审员 需求评审可能涉及的人员包括 需方的高层管理人员 中层管理人员 具体操作人员 IT 主管 采购主管 供方的市场人员 需求分析人员 设计人员 测试人员 质量保证人 员 实施人员 项目经理以及第三方的领域专家等等 在这些人员中由于大家所处的立场不 同 对同一个问题的看法是不相同的 有些观点是和系统的目标有关系的 有些是关系不大 的 不同的观点可能形成互补的关系 为了保证评审的质量和效率 需要精心挑选评审员 首先要保证使不同类型的人员的都要参与进来 否则很可能会漏掉了很重要的需求 其次在 不同类型的人员中要选择那些真正和系统相关的 对系统有足够了解的人员参与进来 否则 很可能使评审的效率降低或者最终不切实际的修改了系统的范围 建议五 对评审员进行培训 在很多情况下 评审员是领域专家而不是进行评审活动的专家 他们没有掌握进行评审 的方法 技巧 过程等 因此需要对评审员进行培训 同样对于主持评审的管理者也需要进 行培训 以便于参与评审的人员能够紧紧围绕评审的目标来进行 能够控制评审活动的节奏 提高评审效率 避免发生案例一和案例二中出现的现象 对评审员的培训也可以区分为简单 培训与详细培训两种 简单培训可能需要十几分钟或者几十分钟 需要将在评审过程中的需 要把握的基本原则 需要注意的常见问题说清楚 详细培训则可能要需要对评审的方法 技 巧 过程进行正式的培训 需要花费较长的时间 是一个独立的活动 需要注意的是被评审 人员也要被培训 建议六 充分利用需求评审检查单 需求检查单是很好的评审工具 需求检查单可以分成两类 需求形式的检查单和需求内 容的检查单 需求形式的检查可以由 QA 人员负责 主要是针对需求文挡的格式是否符合质 量标准来提出的 需求内容的检查是由评审员负责的 主要是检查需求内容是否达到了系统 目标 是否有遗漏 是否有错误等等 这是需求评审的重点 检查单可以帮助评审员系统全 面地发现需求中的问题 检查单也是随着工程财富的积累逐渐丰富和优化的 建议七 建立标准的评审流程 对正规的需求评审会需要建立正规的需求评审流程 按照流程中定义的活动进行规范的 评审过程 比如在评审流程定义中可能规定评审的进入条件 评审需要提交的资料 每次评 审会议的人员职责分配 评审的具体步骤 评审通过的条件等等 建议八 做好评审后的跟踪工作 在需求评审后 需要根据评审人员提出的问题进行评价 以确定哪些问题是必须纠正的 哪些可以不纠正 并给出充分的客观的理由与证据 当确定需要纠正的问题后 要形成书面 的需求变更的申请 进入需求变更的管理流程 并确保变更的执行 在变更完成后 要进行 复审 切忌评审完毕后 没有对问题进行跟踪 而无法保证评审结果的落实 使前期的评审 努力付之东流 建议九 充分准备评审 评审质量的好坏很大程度上取决于在评审会议前的准备活动 常出现的问题是 需求文 档在评审会议前并没有提前下发给参与评审会议的人员 没有留出更多更充分的时间让参与 评审的人员阅读需求文档 更有甚者 没有执行需求评审的进入条件 在评审文档中存在大 量的低级的错误或者没有在评审前进行沟通 文档中存在方向性的错误 从而导致评审的效 率很低 质量很差 对评审的准备工作 也应当定义一个检查单 在评审之前对照检查单落 实每项准备工作 案例五 公司组织结构对项目管理的影响 分析 1 弱矩阵应用 弱矩阵组织保留了职能型组织的许多特点 项目经理的角色更像协调人员而非一个管理 者 对于技术简单的项目适合采用弱矩阵型组织 为什么呢 因为技术简单的项目 各职能 部门所承担的工作 其技术界面是明晰的或比较简单 跨部门的协调工作很少或很容易做 2 平衡型矩阵应用 对于有中等技术复杂程度而且周期较长的项目 适合采用平衡型矩阵组织 采用平衡型组织结构 需要精心建立管理程序和配备训练有素的协调人员才能取得好的效 果 3 强矩阵应用 在强矩阵组织中 具有项目型组织的许多特点 拥有专职的 具有较大权限的项目经理 以及专职的项目管理人员 对于技术复杂而且时间相对紧迫的项目 适合采用强矩阵组织 建议答案 1 项目章程明确责任 资源的冲突主要是项目基线的建设缺乏规范 组员的工作在开始时不明确 项目经 理未能有效管理项目的进度 项目中任何工作上的延误直接影响其他项目的启动和进 度 所以要解决项目经理与部门经理间对资源调配及管理的问题 项目基线的建设机制 包括明确的项目生命周期和合适的开发体系应用 在开发过程中各阶段的工作量及资源 需求 技术 工作范围 责任等 必须明确及合理 要点 在项目章程中为项目经理使用组织资源进行项目活动提供授权 企业必须建立项目基线的建设机制 巩固项目经理本身对项目实施的进度管理 方法 2 项目经理和职能经理的协调 要点 明确部门经理和项目经理职责 其次 部门经理需要下放部分资源分配权 同时 施行项目责任制 再者 部门经理的绩效考核主要依据在各项目经理之间的资 源协调能力 项目质量监管能力 项目经理的绩效考核主要依据项目完成质量 和数量 实行多项目管理 项目经理面对的问题应属于多项目管理的问题 要彻底解决这种局面 还是要从公 司着手 在公司内部要实行多项目管理的方法 例如设立项目资源部经理