2013年下半案例分析题答案11.docVIP

案例分析一： 可能原因如下： 没有进行系统的可行性分析（或风险分析，或没有进行多方案比较） 调研不充分，不了解该技术是否成熟（或没有调研大规模应用的案例） 没有调研国家政策（或法规）是否允许。 李某在实施“快速通”时可能遇到的风险有： 技术风险，李某采用的这种新技术目前还没有成为行业标准。 政策风险，李某涉嫌无照运营，这是目前的政策所不允许的， 市场风险（采购风险），系统运行也有风险，因设备供应商可能倒闭而产生。 2、可行性分析的基本步骤： （1）确定项目规模和目标 （2）研究正在运行的系统 （3）建立新系统的逻辑模型 （4）导出和评价各种方案 （5）推荐可行性方案 （6）编写可行性研究报告 （7）递交可行性研究报告 项目评估报告的内容： （1）项目概况 （2）评估目标 （3）评估依据 （4）评估内容 （5）评估机构与评估专家 （6）评估过程 （7）详细评估意见 （8）存在或遗漏的重大问题 （9）潜在的风险 （10）评估结论 （11）进一步的建议 案例分析二： 1、问题1解答要点如下： 没有按照严谨的变更控制流程对整个需求变更做完整的记录和跟踪。（对于需求变更请求没有记录，没有对变更进行正式的评审和批准，对于变更的结果没有验证）。 对需求变更可能造成的影响没有进行全面的评估和分析（只分析了需求变更对于工期的影响）。 没有修改项目管理计划并重新评审（项目经理不应口头布置任务，同时里程碑的调整没有通知相应的管理层） 配置管理工作没有做好（没有对需求文件和设计文件进行修改，并升级相应版本；相应的模块编码的修改也没有进行版本控制）。 变更结果没有跟客户沟通（需求变更实施后，没有让客户对最终结果进行确认）。 问题2解答要点如下： 没有遵循正式的变更控制流程，可能导致需求变更的过程失控和不可追溯。 没有对变更的影响进行完整分析，可能导致无法全面了解这次变更对项目进度、范围、成本和质量等造成多大的影响。 没有修改项目管理计划可能导致实际工作内容与计划有较大的偏差，使项目管理计划无法指导项目实施。 没有对相应技术文档进行修改，可能导致需求、设计与编码无法对应，不利于后期的测试和以后的维护工作。版本管理和配置管理没有做好，可能导致在变更失败后无法将项目恢复到变更前的状态。 没有让用户对最终结果进行确认可能导致双方对变更结果的意见不一致，不利于项目验收和最终交付。 问题3解答要点如下： 提出书面的变更申请； 对变更可能造成的影响进行评估；（变更的整体影响分析） 提交CCB进行审批。（接收和拒绝变更） 获得批准后，安排相关人员实施变更。 对变更的结果进行验证。（6）对变更的信息进行记录存档。 案例分析三： 问题1解答要点如下： （1）WBS将项目的可交付成果和项目工作细分为更小的，更易于管理的组成部分。WBS的最底层为工作包，最终的工作包都必须有明确可验证的交付成果，逻辑上不可再分，在WBS中需要对各层各个分解进行编码。 （2）创建WBS的主要作用如下。 识别完成项目目标所有的工作 只识别必需的工作 识别工作包以便进行工作估算和指派工作 提供一个衡量项目成功的标准 分清职责 （3）助手的WBS不完整，遗漏了“项目管理这项”工作 2、答案详见课堂讲解。 3、问题3要点如下： (1)在各层次上保持项目的完整性，避免遗漏必要的组成部分。 (2)一个工作单元只能从属于某个上层单元，不能交叉从属。 (3)相同层次的工作单元应有相同性质。 (4)工作单元应能分开不同的责任者和不同工作内容。 (5)便于项目管理进行计划和控制的管理需要。 (6)最低层工作应该具有可比性，是可管理的，可定量检查的。 (7)应包括项目管理工作(因为管理是项目具体工作的一部分)，还要包括分包出去的工作。 4、WBS可以采用多种形式，分解方法有： 使用项目生命周期的阶段作为分解的第一层，而把项目可交付物安排在第二层 把项目重要的可交付物作为分解的第一层 把子项目安排在第一层，再分解子项目的 WBS。 本案例是用的第二种分解方法。 案例分析四： 问题一要点如下：， （1）、从一开始就没有做项目的范围管理工作，或做的不好。 （2）、让用户自己提需求，而不是自己去分析。 （3）、在出现需求变更或变更冲突的时候，也没有相应的变更控制系统来约束，以致局面越来越被动。 2、问题二要点如下： 项目外部环境发生变化，例如，政府政策的问题。 项目范围的计划编制不周密详细，有一定的错误或遗漏。 市场上出现了或是设计人员提出了新技术、新手段或新方案。 项目实施组织本身发生变化。 客户对项目、项目产品或服务的要求发生变化。 3、问题三要点如下： 变更控制系统是定义范围变更的有关流程。它包括必要的书面文件(如变更申请单)、纠正行动、跟踪系统和授权变更的批准等级。 案例分析五： 问题1 关键路径为：ACDGH 项目