软件项目管理案例全答案.docx
《软件项目管理案例全答案.docx》由会员分享，可在线阅读，更多相关《软件项目管理案例全答案.docx（45页珍藏版）》请在冰豆网上搜索。
软件项目管理案例全答案
第一章
案例一：
项目计划编制
参考答案
【问题1】（6分）
小丁在接到任务后开始项目计划的编制工作，编制的计划应包括：
（l）项目总计划（包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划以及费用计划）。
（2）项目辅助计划（质量计划、沟通计划、人力资源计划、风险计划、采购计划等）。
【问题2】（6分）
根据《中华人民共和国招投标法》第48条：
中标人应当按照合同约定履行义务，完成中标项目。
中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。
中标人按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给他人完成。
接受分包的人应当具备相应的资格条件，并不得再次分包。
中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。
本案例中，A公司将子项工程分包给B，B又将其分包给C，显然违背了招投标法的这一条款。
根据条款中的内容：
“中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。
”A公司显然要承担责任，同时B公司也负连带责任。
【问题3】（6分）
本题中，在项目执行过程中，项目发生的变更，程序员小张擅自修改了已进入基线的程序，作为项目经理的小丁不应该默许他的操作，且修改后的东西没有经过评审。
项目中缺乏变更控制的体系，需要建立变更控制流程，确保项目中所做的变更保持一致，并将产品的状态、对其所做的变更，以及这些变更对成本和时间表的影响通知给有关的项目干系人，以便于资源的协调。
同时，项目团队所有成员要清楚变更程序的步骤和要求。
提出以下建议：
（1）建立配置管理体系。
（2）建立变更请求流程。
（3）组建变更控制委员会。
【问题4】（7分）
（1）从项目管理9大知识点出发简单阐述本项目。
（2）从本项目管理较弱的部分进行重点的阐述，如对法律法规的理解（招投标管理）、项目进度管理、项目变更的控制。
配置管理及进度计划的变更将导致质量和成本的变化，描述进度、质量、成本三要素之间的关系。
案例二：
项目启动与项目经理角色
参考答案
【问题1】（7分）
本题中，项目前期的负责人实际是公司副总经理，在项目章程中确定项目经理的人选。
作为项目前期的负责人，在接到项目的任务后将开始项目的启动工作。
项目的启动包括了以下几个主要活动：
（1）识别项目的需求。
（2）解决方案的确定。
（3）对项目进行可行性分析。
（4）项目立项。
（5）项目章程的确定。
【问题2】（9分）
项目时间管理中的重点是把握好关键路径上的任务，项目甘特图绘制如图1-1所示。
项目双代号网络图绘制如图1一2所示。
甘特图与网络图的区别：
甘特图直观、简单、容易制作，便于理解，一般适用比较简单的小型项目，可用于WBS的任何层次、进度控制、资源优化、编制资源和费用计划。
但是不能系统地表达一个项目所包含的各项工作之间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。
采用网络图进行进度控制，能够清晰地展现现在和将来完成的工程内容、各工作单元间的关系，并且可以预先确定各任务的时差。
了解关键作业或某一环节的进度的变化对后续工程和总工期的影响度，．便于及时地采取措施或对进度进行调整。
【问题3】（9分）
项目的质量、进度、成本相关联，因此，在进度控制和成本管理上考虑：
（1）在进度管理上，可以采用加班等方式进行。
（2）投入更多的人力、物力。
（3）把握关键路径上的任务。
在实际处理的过程中，因为新投入人力到项目，而且新的人力对项目的熟悉程度不一，新员工需要经过一段时间的培训才能适应项目，所以，最佳的方式应该是采用加班方式来提前完成项目，同时，项目经理应该调整进度计划，在关键路径上加班，缩短关键路径的长度。
案例三：
项目管理部门职能
参考答案
【问题1】（8分）
从提高软件质量角度而言，企业设立项目管理部门的目的是以独立审查方式，从第三方的角度监控软件开发任务的执行，同时辅助软件工程组取得高质量的软件产品。
从提高软件企业项目管理能力角度而言，项目管理部门可以帮助企业在组织层面上对那些孤立的、无关联的项目进行统筹和管理，从而提高整个组织的项目管理能力，有力地支撑组织战略目标的实现。
由此可知，项目管理部门具有十分重要的存在价值。
现阶段，项目管理没有发挥出应有作用，主要由于广大企业认识不够，经验不足，体系不健全。
但这只是暂时现象，过了这段不稳定期，该部门的存在价值就会发挥出来。
【问题2】（8分）
（1）找一个失控的项目进行管理，使其回到正常的轨道并顺利地完成，使
得领导意识到项目管理部的作用，提升威信。
（2）项目管理规范材料要逐步推行，不可操之过急。
（3）对公司员工进行项目管理培训，尽可能提高他们的项目管理意识。
（4）与公司高层沟通，尽可能获得高层支持，向高层要权。
（5）项目管理部门的职责一般是监控项目实施，主要是发现项目中存在问题并督促项目组解决，而不是解决项目组的问题，那样会招致项目组反感。
（6）项目管理部在职能和行政上独立项目组，而在业务和工作上融入项目组。
【问题3】（9分）
企业项目管理部门在项目开发中的质量管理内容包括以下四部分：
（1）决策阶段
在广泛搜集资料、调查研究的基础上研究、分析、‘比较，决定项目的可行性和最佳方案。
（2）项目实施前
①对项目组的能力重新审查，如果发现实际情况有所变化，必须采取有效措施予以纠正。
②对所有的合同和技术文件、报告进行详细的审阅。
③审阅进度计划和实施方案。
④对项目实施中将要采取的新技术、新软件进行审查。
⑤对项目实施所需材料和设备的采购进行检查。
⑥协助完善质量保证体系。
⑦对各项目组负责人和主要人员进行进一步的审核。
⑧根据项目计划制定与其对应的质量管理计划。
⑨组织质量管理计划的评审，并形成评审报告。
⑩准备好项目人员简历、质量管理表格。
⑩准备好担保和保险工作。
⑩签发动员预付款支付证书。
⑩全面检查开工条件。
（3）项目实施中
①参与项目的阶段性评审。
②参与项目阶段产品的审计。
③对项目日常活动与规程的符合性进行检查。
④对配置管理工作的检查和审计。
⑤跟踪问题的解决情况。
⑥收集新方法，提供过程改进的依据。
（4）项目完成后
①监督检查项目测试情况。
②协助项目组完成项目验收。
③监督检查系统安装、试运行。
④进行项目实施后审计。
⑤总结项目实施的经验和教训。
案例四：
可行性研究问题
参考答案
【问题1】（7分）
可行性研究的步骤包括：
①确定项目规模和目标；②研究正在运行的系统；③建立新系统的逻辑模型；④导出和评价各种方案；⑤推荐可行性方案；⑥编写可行性研究报告；⑦递交可行性研究报告。
【问题2】（8分）
可行性研究报告的编写内容包括：
（1）引言。
（2）可行性研究的前提。
（3）对现有系统的分析。
（4）所建议的系统。
（5）可选择的其他系统方案。
（6）投资及效益分析。
（7）社会因素方面的可行性。
（8）结论。
【问题3】（10分）
项目评估报告一般应包括以下内容：
（1）项目概况。
（2）评估目标。
（3）评估依据。
（4）评估内容。
（5）评估机构与评估专家。
（6）评估过程。
（7）详细评估意见。
（8）存在或遗漏的重大问题。
（9）潜在的风险。
（10）评估结论。
（11）进一步的建议。
案例四：
可行性研究的问题
参考答案：
问题1：
可行性研究的步骤包括：
①确定项目规模和目标：
②研究正在运行的系统：
③建立新系统的逻辑模型：
④导出和评价各种方案：
⑤推荐可行性方案；⑥编写可行性研究报告；⑦递交可行性研究报告。
问题2：
可行性研究报告的编写内容包括：
（1）引言。
（2）可行性研究的前提。
（3）对现有系统的分析。
（4）所建议的系统。
（5）可选择的其他系统方案。
（6）投资及效益分析。
（7）社会因素方面的可行性。
（8）结论。
问题3：
项目评估报告主要包含如下内容：
1）项目概况；2）项目目标；3）项目依据；4）项目内容；5）项目机构与评估专家；6）评估过程；7）详细评估意见；8）存在或遗漏的重大问题；9）潜在的风险；10）评估结论；11）进一步的建议。
第二章
案例一：
范围定义
参考答案：
问题1：
1）张工应该注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
2）张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清楚。
3）张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
4）张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。
5）张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
问题2：
1）张工没有挖掘到系统的全部隐形需求，缺乏精确的范围定义。
2）在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
3）重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
问题3：
在有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作倒是重要的。
对于本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法辅助需求的定义，避免范围定义不清晰的问题。
在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚决避免需求的再次变更。
案例二：
工作要点
参考答案：
问题1：
1）张工首先对最初的项目范围进行了清晰的定义，并根据定义对工作进行了分解，指定了WBS。
2）张工对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握。
3）在出现新的项目目标后，张工对项目进行了范围控制，缩小了第一阶段实现的范围。
4）张工对重新定义的项目范围进行了确认，与高层经理和客户达成一致。
5）张工对项目进行了沟通管理，协调了多个项目干系人之间的矛盾。
问题2：
项目范围管理的要点：
1）范围管理计划。
2）范围定义。
3）工作分解。
4）范围确认。
5）范围控制。
在本案例中，张工首先进行了范围定义和工作分解，得到了清晰的项目范围；在出现新的项目目标后，张工进行了范围控制，重新定义了两个阶段的项目范围；最后，张工将重新定义的范围与项目关系。
案例三：
范围确认（*）
参考答案：
问题1：
1）张工为了更明确地把握系统需求，聘请了原系统的需求调研人员李工，提高了需求定义的效率和质量。
2）张工没有对李工开发的系统需求进行评审和复查，从而使得需求的缺陷没有被及时发现。
3）张工没有要求用户对已经定义的需求进行确认，从而导致需理解的偏差。
4）张工对需求的不能进行缺乏有效控制，最终造成项目延期50%。
问题2：
该项目实施工程中的主要问题包括：
1）在范围定义中，张工没有对李工定义的需求进行评审，造成需求的质量缺陷没有被及时发现。
2）在范围确认中，张工没有主动地要求用户对需求进行确认。
3）在范围控制中，张工无法进行有效的范围控制，最终造成了重大的需求变更。
问题3：
对于本案例，项目经理需要对需求定义的结果进行质量控制，采取评审等方式减少需求中的问题。
对已经定义的需求需要与用户进行确认，保证双方理解的一致。
在发生需求变更时，也应该采取灵活的手段，在满足用户需求的前提下，尽量减少需求变更的范围。
第三章
案例一：
时间管理
参考答案：
问题1：
本题的关键是确定关键路径，完成这一项目要花43天。
如果不加班，完成此项目的成本是103150元。
问题2：
项目可以完成的最短时量是30天，在最短时间内完成项目的成本是127650元。
问题3：
在关键路径2-3“向最高管理层提交项目计划和项目定义文件”进行赶工2天后，在关键路径4-6“开发和编写实际网页代码”上赶工1天，同时，在4-5“开发电子商务平台数据库”也必须赶上1天。
问题4：
总共需要赶工8天，在2-3“向最高管理层提交项目计划和项目定义文件”上赶工2天，在1-2“比较现有电子商务平台”上赶工3天，在4-5“开发电子商务平台数据库”，4-6“开发和实际编写网页代码”上赶工2天，在8-9“测试，修改”上赶工1天。
在35天内完成项目将花费为113400元。
案例二：
关键路径（*）
参考答案：
问题1：
问题2：
关键路径为4条：
分别为：
ACFIL、ACFJL、ACEGIL、ACEGJL、
问题3：
作为项目经理，要花费18天时间完成项目。
如果在任务B上迟滞了10天则整个项目进度将退后9天。
案例三：
进度计划（*）
参考答案：
【问题1】（6分）
①并没有表现出任务G的进行的前提条件是任务B、C、D的完成。
②6个基本参数的计算：
s1-2=0
EFl-2=0+5＝5
ESl-3＝0
EFl-3=0+6=6
ES2-3＝5
EF2-3＝5＋5＝10
ES2-4=5
EF2-4= 5+4＝9
ES3-5＝10
EF3-5＝10+5＝15
FFl-2＝min|0, 0|＝0
ES6-8＝23
EF6-8＝23+5 =28
ES7-8＝25
EF7-8＝25+4＝29
计算最迟完成时间、最迟开始时间、总时差，其计算顺序是从后往前计算的。
LF7-8＝29
LS7-8＝29一4＝25
LF6-8＝29
LS6-8＝29一5＝24
TF6-8＝29一28 =1
LF6-7=25
LS6-7=25一2＝23
TF6-7=25一25 =0
LF4-6= 23
LS4-6=23一6=17
【问题2】（6分） D：
计算进度第9天完成。
实际第（12+4-2）＝14天完成，拖期5天。
E:
计算进度第15天。
实际第（12+3）=15天完成，说明进度正常。
【问题3】（6分） D工作最早完成时间为第9天，E工作最早开始时间为第10天，设备闲置1天；工作为第15天，I工作为第23天开始，设备闲置8天；故设备总共闲置8+1=9天。
【问题4】（7分）
原计划工期TC=29，时间发生后TC=30。
因此，延迟的工期天数为1天。
案例四：
进度估计（*）
参考答案
【问题1】（10分）（图3-13）
【问题2】（15分）
措施：
在概要设计B完成后即开始制定移交计划P。
理由：
a．原有计划的关键路径是
，只有设法缩短这条路径才行。
b.
不能缩短，而缩短设计工作的时间又会产生不良的后果。
c.根据新系统的特性，在概要设计完成后就完全可以着手制定移交计划。
这样做可以允许多用3个月的时间把移交计划和移交工作做得更好。
第四章
案例一：
成本估算
参考答案：
问题1：
信息系统项目进行成本估算的基本方法包括：
1）自顶向下估算或类比估算法。
2）自下而上估算法。
3）参数估算法。
4）专家估算法。
5）猜测估算法等。
问题2：
表4-1采用了自下而上的成本估算方法，表4-2采用了参数成本估算方法，经计算，两表中国估算值A为202000元，B为111820元。
问题3：
综合起来，信息系统的项目成本估算的困难主要包括以下方面：
1）需求信息的复杂性。
2）开发技术与工具的不断变化。
3）缺乏类似的项目估算数据可供参考。
4）缺乏专业和富有经验的人才。
5）信息系统研发人员技术能力的差异。
6）管理层的压力和误解。
在对项目进行成本估算时，应该避免以下的常见错误：
1）草率的成本估算。
2）在项目范围尚未确定时就进行成本估算。
3）过于乐观或保守的估算。
案例二：
成本估算
参考答案：
问题1、问题2、问题3参考答案见表4-5
问题4：
根据图4-1和4-5计算每周费用总和，如图4-5所示：
案例三：
挣值管理（*）
参考答案：
【问题1】截至项目状态日期已经完成工作量的预算成本，即挣值EV：
EV=50×50%=25万元。
【问题2】项目结束时的总成本：
EAC=28÷50%=56万元。
【问题3】由于AC>PV>EV,说明项目实际费用支出超前，与实际完成工作量相比费用超支，项目实际完成工作量与计划工作量相比出现拖期。
【问题4】重新预计的项目完工总成本：
EAC=（28-4-3×（1-40%））÷50%=44.4万元。
案例四：
成本控制（*）
参考答案
【问题1】（6分）
应当先估算各模块的工程量，再以工程量来估算所需要的人力资源，如总工程量“××人周”或“××人月”或“××人年”等。
李工的项目小组的建设应分阶段进行人力资源投入，如设计阶段所用人力应较少，而详细设计完成后，编码阶段进入，则人力投入是高峰期。
人力资源成本的预算也应当核算一定比例的浮动成本。
李工所采用的是挣值管理方法。
此方法应用到软件工程项目中，应注意软件开发挣值与投入的非线性比例关系特点。
【问题2】（10分）软件开发人力资源成本挣值统计是能够做到比较准确的，衡量软件开发人力资源成本的计算公式：
累积人力资源成本=
模块工作量i×完成率i×平均人力周成本
李工所采取的方法应增加各模块工程量的估算，就能够进行人力资源成本控制。
如表4-11所示。
实际消耗的人力资源成本可通过财务发放的工资统计得到。
【问题3】（9分）
李工根据各工程师的进度报告（进度百分比）来计算挣值，在软件开发中是不可行的。
在软件开发中，各模块的进度百分比通常很难测量准确，而各工程师的汇报往往是很粗略的估计，这种估计只能提供给项目经理控制进度时做参考，但不能作为成本核算或申请工程进度款支付的依据。
建议李工以各模块全面完工来进行计算，即各模块要么计算0％，要么计算100%完工，但在进行工作分解的时候，分解的深度和各模块的粒度要合适，便于进行控制。
另外，在核算的时候，要扣除一定的比例，如20%～30%作为各模块集成所需要的工程量，待工程全面完工后进行核算。
案例五：
投资决策（*）
参考答案：
【问题1】
刘工的分析不全面。
全面的经济分析还应考虑“成本回收期”、“追加成本净现值”、“追加成本内部收益率”、“内含报酬率”、“敏感性分析”等。
还应当增加投资风险分析，本案例方案B的投资风险比方案A的投资风险小。
【问题2】
B方案分两期建设，两期投入建设资金。
由于B方案的一期系统建设在一年建设完成后就投入运行，产生了经济效益。
因此，通过净现值指数分析，B方案净现值指数高于A方案，B方案的经济性比A方案优越。
B方案分两期投入，项目风险将会得到一定程度的降低。
B方案所投入的资金多于A方案，一般有以下原因：
两个分立的合同，在甲乙商务方面将有一定区别，分立合同的单价往往会做得高一点。
●由于分期建设，在应用系统的体系架构方面，可能有一定程度的重复开发。
●由于分期建设，硬件及采购设备方面可能有部分会被淘汰、升级，从而影响采购投资方面的增加。
●由于分期建设，IT项目市场环境、技术、政策等因素的影响，也会导致投资总额差别。
【问题3】
从技术经济性上讲，A、B两方案均是可行的。
但B方案更好。
B方案比A方案风险小，且B方案建设周期短，见效快。
采用B方案，应注意应用系统开发的统筹规划就更好了，可以采取一次规划，分期建设，在一期工程建设的时候，对=期工程的建设做比较全面的分析，使一期工程在技术上能够较好地支持=期工程。
如果采用A方案，也可以实现部分功能模块提前投入运行，产生经济效益。
甲乙双方只签一个合同，在投资不变的情况下，提前实现收益，使收益增加，提高项目的经济效益。
第五章*
案例一：
计划及跟踪
参考答案
【问题1】
张工安排测试计划的编制时机不对。
测试计划和测试用例的编制应当与软件系统的概要设计、详细设计同步进行。
测试计划不够全面，还应当包含系统整体测试、运行测试。
运行测试是对应用软件系统整体功能的全面检验，也是最能够说明软件系统质量的测试环节。
系统测试计划、确认测试计划应当在需求分析阶段制定，测试用例、测试说明应当在概要设计阶段制定。
集成测试计划应当在概要设计阶段制定，测试用例、测试说明应当在详细设计阶段制定。
单元测试计划应当在详细设计阶段制定，测试用例、测试说明应当在编码阶段制定。
【问题2】
在定制软件开发项目中，根据测试结果判定软件系统的质量是不够的，因为软件系统中的缺陷可能由于多种原因而未在测试中被发现，如测试环境与运行环境的区别、测试人员的能力问题、测试计划和测试用例的局限及缺陷。
由于软件系统质量、功能、性能具有很强隐蔽性的特点，用户往往不大可能根据项目开发小组的测试结论来进行项目的验收。
最好让用户组织对项目进行试运行，以试运行的结论来作为验收的依据之一是比较有说服力的。
【问题3】
（1）在进行需求分析的时候，同步制定功能确认测试计划和测试用例，同步制定系统整体测试计划和测试用例。
（2）在进行软件系统概要设计的时候，制定集成测试计划和测试用例。
（3）在进行软件系统详细设计的时候，制定单元测试计划和测试用例。
（4）在项目计划验收日期前，提前与用户协商系统试运行计划，并给用户进行充分的培训，包括领导和一般操作人员，让系统接受实际运行的考验，在试运行过程中暴露出来的问题，及时进行解决。
以软件系统实际运行所表现出来的功能、性能来说服用户对项目进行验收，这通常是更可行的方法。
案例二：
团队协作
参考答案
【问题1】
现场用户的需求是不可能有尽头的，但作为项目经理要能够把握住用户的需求，特别是要合理引导用户需求，切不可让用户怎么说就怎么做。
积极响应客户需求要从多个方面着手考虑，不要只从技术上考虑问题，技术引导、合同变更、人力资源等各个方面都应当考虑。
临时的现场开发工作，大多数都不可能与公司总部的软件开发融为一体，而且管理工作常常是自上而下的，李工忽略了这点，顾此失彼，导致项目问题的发生。
造成项目问题的原因有以下几点：
李工对需求把握随意；控制不严；李工与客户沟通不到位；李工没有向客户提交合理的进度计划，或没有按时提交进度报告；项目实施无计划，或计划不能得到客户认可，客户不满意。
【问题2】
团队协同开发软件时，很容易出现软件版本管理不善带来的软件系统故障。
同一软件系统代码不能同时由多人进行修改。
项目现场为应急而擅自更改软件代码，而常常没有将更改纳入统一的版本管理，很容易造成总部发行新版本软件时，替换软件而丢失了现场所进行更新的代码，从而造成系统故障反复出现。
李工如果一定要进行现场开发，应当委托现场合适的人员，或亲自督促现场所进行的开发工作与总部所进行的开发工作在软件版本方面保持一致，处理本地过于偏激的需求要与总部协商一致的情况采取合理措施控制统一版本。
【问题3】
项目现场应明确自己的工作职责范围，要自觉与总部门形成密切的配合。
现场所做的开发，应与总部所做的开发纳入同一个软件版本管理。
当现场发现软件故障时，应当及时向总部报告。
建立故障管理表，记录并跟踪软件系统故障解决情况。
建设一个软件开发交流平台，如基于Internet的管理平台，管理工程现场所提出的问题，调度、跟踪解决工程现场问题。
现场工程人员与总部人员应多交流，通过各种方式，如及时通信软件、电话、电子邮件等，必要时，可组织研发部给现场工程人员进行培训。
案例三：
质量与成本
参考答案
【问题1】
CSAI压缩项目工资支出不合理。
压缩工资支出必然导致压缩项目小组的整体能力或平均技能水平。
如果压缩平均技能水平，将使软件
升级会员 