系统集成项目管理工程师教程第23章案例分析参考答案.docx
- 文档编号:10884057
- 上传时间:2023-02-23
- 格式:DOCX
- 页数:17
- 大小:1.66MB
系统集成项目管理工程师教程第23章案例分析参考答案.docx
《系统集成项目管理工程师教程第23章案例分析参考答案.docx》由会员分享,可在线阅读,更多相关《系统集成项目管理工程师教程第23章案例分析参考答案.docx(17页珍藏版)》请在冰豆网上搜索。
系统集成项目管理工程师教程第23章案例分析参考答案
案例一:
人力资源负荷优化案例
【问题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】计算该项目自投资当年起的静态投资回收期和动态投资回收期(要求列算式),并说明两者存在差异的原因。
◆资金的时间价值:
指货币随着时间的推移而发生的增值,也称为资金时间价值。
◆现值(Presentvalue),也称在用价值,指资产按照预计从其持续使用和最终处置中所产生的未来净现金流入量折现的金额。
通常又称“本金”。
通常记作P
◆终值(futurevalue),又称将来值或本利和,是指现在一定量的资金在未来某一时点上的价值。
通常记作F。
◆单利终值:
F=P+P×i×n=P×(1+i×n)
式中,1+n×i——单利终值系数
【提示】除非特别指明,在计算利息时,给出的利率均为年利率,对于不足一年的利息,以一年等于360天来折算。
◆单利现值
现值的计算与终值的计算是互逆的,由终值计算现值的过程称为“折现”。
单利现值的计算公式为:
P=F/(1+ni)
式中,1/(1+ni)——单利现值系数
◆复利终值
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)表示。
◆投资回收期是指用投资方案所产生的净收益补偿初始投资所需要的时间,其单位通常用“年”表示。
◆静态投资回收期是不考虑资金的时间价值时收回初始投资所需要的时间。
⏹公式:
Pt=累计净现金流量开始出现正值的年份数-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<0=>EV SV=EV–PV=3820-(200+220+400+250+300+540+840+600+240+150+1600+2000+100)=3820–7440=-3620<0=>EV 题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、项目经理和职能经理的协调 要点: ◆明确部门经理和项目经理职责,其次,部门经理需要下放部分资源分配权,同时施行项目责任制,再者,部门经理的绩效考核主要依据在各项目经理之间的资源协调能力,项目质量监管能力,项目经理的绩效考核主要依据项目完成质量和数量 ◆实行多项目管理 项目经理面对的问题应属于多项目管理的问题。 要彻底解决这种局面,还是要从公司着手,在公司内部要实行多项目管理的方法,例如设立项目资源部经理,公司人力资源统一由资源部经理统一分配,项目所需要的人员要从公共资源库中挑选,再分配到项目中来。 由于公司人员短缺的实际情况,短期的解决方法就是把同一个项目经理负责的项目合并为一个大项目,每个项目为大项目中的一个子项目,为每个子项目设立优先级,优先级高的有获得资源的优先权。 ◆发现问题,及时沟通 当发现某组员的工作可能受到延误,不能如期在指定时间释放该组员时,应尽快与该组员的部门经理及等待接收该组员的项目经理进行沟通,提出有关风险,让其他项目组能够尽早建立应变措施,调整工作计划,或另找其他资源代替。 尽量降低项目组与部门间,或项目组与项目组间的争议。 综合案例一: 变更控制
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统集成 项目 管理 工程师 教程 23 案例 分析 参考答案